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. . .
<timbl> http://lists.w3.org/Archives/Public/www-tag/2002Nov/0156
<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]
<dino> http://www.w3.org/2004/07/webapps/webapps
DJ: Draft charter is in W3M
review
... WebApps have become cool again in the last 12--6 months,
particularly AJAX, based on XMLHttpRequest
<timbl> HTML, DOm, Javascript, XMLHttpRequest
DJ: Technology has been around,
but only crystalised recently
... Gmail is a good example of HTML+DOM+Javascript
... Whole mailbox is one page, mail comes in/out via Javascript
plus HTTP requests behind the scenes
... 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.
... But I thought this was about refining/standardising
existing hacks, i.e. standardising Javascript usage of
today
<timbl> Dean: The DOM is used in Javascript, but in Python one could do a much better specific language binding.
DJ: Yes. C.f. the reaction of the dev community to the DOM -- we're only going to use it through Javascript, so the cross-language stuff is a pain
<timbl> It should be extending and refining existing practice ... but Java is often used when Javascript is not on phones.
DJ: So mostly yes, Javascript,
but phones are a worry, because Java, not Javascript, is the
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
... The focus is on standardising across the current diversity
of Javascript usage into specific W3C-blessed APIs
<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: Can easily make it less Javascript specific
TBL: But is that really the right direction to go -- don't you lose fluidity if you move away from Javascript-specific -- consider E4X, tightly coupled to Javascript and very clean as a result
DJ: Compare Java, strong-typing,
vs. Javascript and Python, can change type at runtime
... Main usecase is Javascript, I'm happy to put that in the
charter
<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
bulk of Javascript art is figuring out what support you've got
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
<DanC> Mobile Code Workshop: 05 July 1995
DJ: Answer: 1 -- even phone
platforms are moving towards Javascript
... [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
like Javascript
... 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
experience
... Biggest difference between Javascript and Python is that
Javascript shares code by copy and paste, because of security
restrictions
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
<Zakim> DanC, you wanted to ask about javascript importing: namespaces and security
DC: Is Javascript's namespace flat?
DJ: Yes -- the charter talks
about the 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
charter?
DJ: Yes, called Global Browser
Object
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
etc.
... And an open-standard programming environment
... Javascript is good enough, maybe XUL is good enough, but
nothing comes close in terms of current usage to
HTML+Javascript
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
do
... 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
<DanC> XBL (Extensible Binding Language) 1.0
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)
DO: Is managing the growth and manipulation of complex state in Javascript to protect against the loss of URIs for the results on the table?
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")
TBL: Question for the TAG: Are we happy with the Web losing its declarative style, more and more going in to Javascript?
DC: No not happy, see Tim's pending action wrt Principle of Least Power
DJ: There are some really bright
Javascript hackers who, e.g. to populate a page, will use
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?
<DanC> (there's some company that has done an XForms implementation in javascript... what's it called?)
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
<dino> yes
HST: If WHATWG are targetting the 80/20 point and doing it declaratively, why aren't we?
DJ: They're not doing things
completely declaratively
... E.g. a slider which looks like a text box today, a slider
if you have an 'HTML5' browser
... Maybe they could add some javascript to get an intermediate
behaviour
... 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: Agreed
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
<DanC> OpenID: an actually distributed identity system
DC: Turns out things aren't so
bad
... 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