See also: IRC log
<DanC> expecting Ed and Timbl
DO to scribe next week
<DanC> regrets NM for 12 July
TimBL: Existing issue XMLProfiles-29. . .
<DanC> Issue withdrawn by the tag http://www.w3.org/2001/tag/2004/11/29-30-tag#item17
TimBL: we withdrew our request to
XML Core to do something
... but not clear that the issue is really dead
<DanC> (the norm is that the TAG announces a decision to close an issue, saying to the originator, "ok with you?")
TimBL: need to check with Paul Grosso and Norm Walsh
<timbl> There should be a message to say what the tag resolved.
<timbl> Or that it was withdrawn by Paul G
<scribe> ACTION: Chair to check status of XMLProfiles-29 with Paul Grosso [recorded in http://www.w3.org/2005/07/05-tagmem-minutes.html#action02]
VQ: Thanks to Dean for joining us
so late in the day in his timezone
... [background to TAG interest in Web Applications]
DJ: Draft charter is in W3M
... WebApps have become cool again in the last 12--6 months, particularly AJAX, based on XMLHttpRequest
DJ: Technology has been around,
but only crystalised recently
... Same URL throughout the whole session
... Another example is Google Maps
... Dashboard widgets. . .
... Devs complaining about limitations, requests coming in to W3C for support/features
... Some of this has filtered in to our specs, e.g. SVG
<DanC> hmm... yes... what deliverables/scope?
DJ: But SVG is not really the right place for a Network API -- we maybe need a REC which addresses these issues across all the relevant domains
TBL: Is this an ECMAScript-based
story or not
... Scope says just "client-side applications for the web" -- that covers Perl, Haystack etc.
tool of choice there
... Also, consider XMLHttpRequest - not needed in Java, it's already there
... Cookie-support OTOH is something which makes sense in the browser context, not in the general web/pgming language interface
<DanC> (hmm... in fact, skip the specs and go straight to the test suite. just give this WG the mandate to decide the outcome of test cases presented by the community. 1/2 ;-)
TBL: The charter should say this -- no sense beating around the bush, stop people from joining to design a new language in their tracks
DJ: Take that on board
TBL: First deliverable is a list of deliverables?
DJ: That came from W3M input
HST notes that writing a Requirements doc't is often the way a new WG starts. . .
TBL: I'd worry that that opens
the door to new languages
... Compare what's happened to CDF -- embedding is the interesting and important bit, but they're focussing on 'by reference', because it's the easy part
DJ: Well, we hope the problems we're solving wrt 'by reference' will make the embedding part easier when we get to it
TBL: Scoping is really important. . .
DJ: Compare Java, strong-typing,
<Zakim> DanC, you wanted to ask about how many programming languages in the web...
TBL: People have said the the DOM is clumsy -- OK for all languages, but good for none.
DC: E4X looks good, cool if
runtime understands it, but it's my understanding that the huge
for what features and how you can do business
... Architectural question: How many programming languages for the web -- Ref. Programming Languages workshop in 1995 (ref below), concluded in favour of 'many'. But by 1997, with COM, CORBA and Java in play, with MSoft opposed to anything beginning J*, we then went on to do our first, namely XSLT
... So 'how many' is still an interesting question
DJ: Answer: 1 -- even phone
... [something] from Microsoft coming along for phones, embed any .NET language
DC: Languages I run in to: Flash/Lingo
DJ: Lingo is changing to be more
... Nice pgrming environment, simpler object setup than HTML
<DanC> ActionScript is more like...
DC: ActionScript is compiled out,
there's XSLT, Java . . . not growing all that fast in my
DJ: But the <script> tag
can reference anything and it will get downloaded
... But once you're running, the code can only retrieve from the place the matrix page came from
... Reason is to stop people snarfing stuff from inside the firewall once they get there
DJ: Yes -- the charter talks
Window object, which is not standardised anywhere but
implemented in all browsers
... If you expect to share code, use xx_ in front of all your names
TBL: Is the
Window thing in the
DJ: Yes, called
TBL: Any pointer to anyone's documentation of this would be good. . .
DJ: Yes, 2nd deliverable is a "State of the WebApp World" -- that could include e.g. a Wiki collected by Team cataloguing everything we can find . . .
<DanC> hmm... TAG finding ?
DJ: It would be good IMO to move
this off the WG and onto the Team
... Question: Google Accelerator pre-fetched links from search result, but this caused trouble by stimulating lots of server-side code
... Non-bookmarkable stuff that just blew up
<DanC> (er... GET vs POST is one issue (#7) and bookmarkable-cookie-state is another (not on our list yet?))
TBL: The principle of GA is OK
[HST doesn't understand why POST would be better]
DJ: Lazy use of GET to save 2 lines of code
<DanC> (using POST in the right places isn't helped by some aspects of HTML)
VQ: When we discussed this last week, NM asked about open architectures wrt WebApps -- comment?
DJ: Not sure what he meant by that
DC: Worried about monopoly control of the design space
DJ: Everyone shares that concern:
An open-standard document format that can do text animation graphics
... And an open-standard programming environment
VQ: NM also concerned about client-side memory requirements
<DanC> (dean, if it's been in IE for 7 years, surely there's some docs somewhere)
DJ: Think that's a misunderstanding, hope current charter clarifies, persistent storage is not a requirement
<dino> there are. somewhere on msdn.com
<dino> I'll look
TBL: Make sure there is more than one line in the charter in terms of answering this sort of question, so that scope is clear
DJ: RF mentioned security, something will go in charter
<Zakim> ht, you wanted to ask about POST
<DanC> (using GET for "buy this album" is lazy)
HST: Why is GET the wrong thing?
DJ: Use <a> in a ToDo list
as a way to build a 'done' button
... So prefetching from the todo list dropped all the items
<Zakim> timbl, you wanted to ask about Dean's personal prioritization of these issues, and interdependencies
TBL: Suppose you were chair, how do you proceed? Fork multiple taskforces, because things are independent?
DJ: Yes, multiple task forces
would be the plan, group as a whole would not have much to
... Most important bit is XMLHttpRequest -- WHATWG is also doing this, as part of HTML5, we could/should do it just on its own
... Another important bit is DOM level 3 Events, it's in Process limbo, needed in lots of places
... Lots of interest in XML UI, I'm not really up on that, lots of folk are concerned to get a standard before we get a lot of non-standard ones
TBL: Start from XUL?
DJ: Maybe, I don't really know enough
TBL: Separate WG?
DJ: Maybe -- there is a risk the WebApp
WG gets all the bits that have no home
... I'd rather make this a small group with small target and get it done
... So keep XML UI out of it
TBL: [missed this]
DJ: Let's see what the AC review says
DC: There's a risk, at formal review stage, that they just say 'yes' and you're stuck with it all
<DanC> TBL: to give the same group both (1) a list of small manageable tasks and (2) a big open-ended thing is to put both at risk
TBL: This all sounds right, you've got the energy pointing in the right direction, XUL is the outsider, best to leave it out
DJ: Right, don't want to get bogged down -- focus on refine and standardise existing practice in the API area/runtime library
TBL: But not a new declarative language for UI, i.e. XUL
DJ: Another relevant point is XBL2, could connect up with taskforce in WebApp WG
DJ: Implemented in Mozilla
DJ: So I hear [TBL] with his W3M hat on suggesting moving the XML UI stuff out of this charter
TBL: Yes, needs more investigation and isn't as ready yet
<DanC> note also... SVG's XML Binding Language (sXBL)
DJ: No, that's not on anyone's radar
DO: So the long-term effect of these problems is not an issue
DJ: Similar to Google Accelerator problem, they did a simple obvious thing but it had unexpected negative consequences
DO: Is there anything the TAG can do about it? How can we help make there be more URIs/make the Back button work
DJ: People are using Ajax because
they believe the user experience is enhanced because it makes
things so much faster than reloading the whole page
... That view is in direct tension with making the Back button work
DC: These guys are savvy wrt what they're doing, but consider when that approach/toolkit is used for a bank website and we move from my statement to a deposit etc. w/o a change in URL
DJ: Well, guidelines on what you shouldn't do would be a good idea -- for example "Don't use GET for things that change the world"
<DanC> (for webaps... forget specs... build a cool "planet webapps", with a validator, complete with a button "I'm surprised by the validator results, and I hereby donate this to w3c as a test case")
DC: No not happy, see Tim's pending action wrt Principle of Least Power
DJ: There are some really bright
microparsing of info in the page and templates to do the job
... So even w/o scripting you can get some sense of what the page is
... WHATWG is making very good progress on that front
... TV Raman said, W3C's job is to watch what's happening on the Web, take non-declarative usages and move them into a declarative form -- XForms is his positive example here
VQ: So will WebApp WG feed back to XForms?
DJ: Not as such, but I do want to know what the XForms people think about WebApps
TBL: Could you write XForms using WebApps?
DJ: Sure, mostly if not all -- Schema?
TBL: So is that a kind of transition strategy?
DJ: Yes, try to put as much declarative stuff into the doc't as possible, a bit of script to do the clever stuff
HST thinks Dave Ragett's SLIDY is a similar story
HST: If WHATWG are targetting the 80/20 point and doing it declaratively, why aren't we?
DJ: They're not doing things
... E.g. a slider which looks like a text box today, a slider if you have an 'HTML5' browser
... I certainly think the XHTML WG think moving stuff into declarative form is part of what they're doing in XHTML2
DC: Not sure what we do next
DJ: Nokia did ask for State of the Art document
DC: Yes, TAG should review the final proposed charter
VQ: Thanks to Dino for his coming to talk to us
<DanC> 28 Jun minutes
DC: says "Draft" all over it
VQ: Title is wrong
<DanC> "Scribe.perl diagnostic output"
<scribe> ACTION: HST to fix all that [recorded in http://www.w3.org/2005/07/05-tagmem-minutes.html#action03]
RESOLUTION: Approved after fixes
DC: Took an action to write a report on sorry state of things
DC: Turns out things aren't so
... OpenID Looks promising, not yet sure it's a complete solution
... Pain point is blog spam, anyone can add irrelevant or unpleasant 'comments' on a blog
... Idea is you add a pointer to e.g. your home page which in turn provides a secure guarantee that you do in fact control that page
HST: Doesn't stop people doing blog spam, just makes them reveal who they really are when they do
DC: Yes, increases the cost of bad behaviour
VQ: What's plan wrt the action you took
DC: I hope to write a report saying "OpenID saves the day", but not before end of summer, I expect
VQ: End of agenda, AOB?
... Meeting over, next meeting next week same time and place
<DanC> let's see... we have regrets from timbl (among others) next week, right?
<timbl> I gave my regrets at the face-face on the board and in email to Vincent