See also: IRC log
stuart reviews the agenda
noah points out that dave won't be available until later and suggests that we do Henry's item first
Stuart describes the work he's done trying to organise themes for the tag and reviewing the issues list
TVR: we might want to finish a little later today than tomorrow
SW: That is the plan.
TimBL: we should remember that we've had a year of doing rather fragmented things and we should try and be more focussed on getting text out and pulling things together.
Regrets from Dave Orchard but hoping to be here via phone/shared whiteboard
Regrets also from Ed Rice
<ht_mit> http://lists.w3.org/Archives/Public/www-tag/2007Feb/0029.html
Minutes duely approved
SW: proposal for next face to face is May 30 to Jun 1
<DanC_lap> " I propose that
<DanC_lap> we schedule our next F2F meeting 30th May-1st June 2007 in the San
<DanC_lap> Francisco Bay Area with apologies to Henry."
<DanC_lap> TVR has volunteered to host
TVR: would like to confirm today to be able to sort logistics
NM: points out that there are limits on flights from SF eastwards for US and Europe
SW: points out that earlier in the week is difficult because of public holidays
HT: points out that he has a family conflict but may well be able to attend
TVR: asks whether we need 3 days for the meeting or not
NM: we need to be able to resolve this now because of flight bookings
There is some willingness for some people to stay longer
Stuart proposes the 30th to the 1st
<DanC_lap> 2.5 days works for me
Discussion about the availability of flights. Proposal to start as early as possible to get the most value from the third day
TVR: points out that it is easy to start at 8 and that we can have breakfast during the meeting
No dissent
Resolved to meet May 30th to June 1st
<DanC_lap> half day on 1 Jun
NW: What about dates beyond that
SW: TimBL has proposed a two day meeting in Southampton in September
... Dave has a preference to avoid the Monday
TimBL: I have a meeting that is scheduled for the Wednesday. I could look at it.
SW: we'll come back to that one
... reviews notes taken during calls with TAG members. Suggests using this as a basis for reflection.
... invites Henry to comment on recent peer to peer meeting
HT: Peer to peer has come up a number of times in previous discussions about TAG work
... Similar questions to web services. Is peer to peer part of the web. Does webarch need to be changed to accomodate it
... maybe its outside the web. I don't have a particular opinion on this.
... invite to MS cambridge was because they are doing lots of things around peer to peer and they would like to know the answer to that question too
... which aspects of the Old Fashioned Web are appropriate for peer to peer
TVR: Looking at lots of things like bit torrent and others, the mechansims are outside the web, but the discovery and publishing is via HTTP
NM: That suggests that we do have a role in aspects of peer to peer.
TimBL: We do have a role in looking for the potential cracks between different aspects. Supports doing things on the fringes. Supports the idea of doing peer to peer specifically.
... HTTP should go in a peer to peer direction.
NM: I want the links to work as expected. I don't expect to need to supply information about the user agent to use
<ht_mit> http://www.ltg.ed.ac.uk/~ht/p2p_notes.html
<Zakim> DanC_lap, you wanted to agree with TVR that p2p is orthogonal to some point, with 2 exceptions: (1) naming, (2) who gets to say what's the right answer to a get/fetch
<Zakim> timbl, you wanted to sy that lookibg at things on the fri nges of web acrh is important, and very much support P2P as a topic.
DC: where it interacts with web architecture are naming who gets to say what the answer is when you do a fetch
VQ: : not only can you discover what you want on peer to peer, but also there can be web-based interaction to perform additional function while you are accessing the peer to peer content
... Boundary between peer to peer and web is more difficult to establish than for, say, bit torrent. Streamed TV is a good example.
HT: These are my notes of meetings with individuals. Goes through them
<DanC_lap> re uplink bandwidth... and universities... NAT vs IPV6?
<timbl> HT: No, NAT is not an issue, it is uplink bw
HT: p2p needs to be more like the OFW with respect to proxies, chunking. There are special purpose proxies that capture and redistribute content.
<timbl> OFW = Old-Fashioned Web, it seems
HT: encryption defeats this.
<DanC_lap> hmm... encryption... again, IPV6 gets in the way?
HT: Lot's of metadata, but not standardised, so can't be shared. No interest in sharing metadata
TVR: Privacy is one reason why this doesn't happen
HT: p2p support is built in to Windows XP and later
... There are legitimate reasons for encryption, beyond hiding the fact that copyright material is being exchanged
SW: The industry might want to protect its content by encryption
TimBL: This happened in the satellite industry when uplinks used to be in the clear. Once peopole discovered how to access the feeds, encryption was used to protect them
HT: There are security issues during legitimate p2p. There are possible attacks, including DoS.
<DanC_lap> the name "sybil" attack makes sense to me, in the context of "Sally Field gives an outstanding award-winning performance as Sybil, a disturbed young woman who suffers from multiple personality behavior." http://movies.yahoo.com/movie/1800124802/info
HT: There are multiple ways of structuring torrents, including ones based on random numbers
TimBL: Akamai works in a similar way
HT: Clients can be download only, which is antisocial
TimBL: But some places don't have the bandwidth for upload
<DanC_lap> ("the venice project" and "joost" are synonyms in my brain. Am I conflating distinct things?)
HT: That is one of the issues with the Venice project.
VQ: It's 300 megabytes per hour, which is ok within regular ADSL
HT: Admits a misunderstanding on the numbers
... Hashes are an issue for security on p2p
DanC: Elaborates that old PCs can be employed for collaborating in caching
TimBL: This works for particular communities
DanC: LOCKSS Lots of Copies Keeps Stuff Safe
... LOCKSS is operations research. How to do the caching with low maintenance
<timbl> The whole desigtn assumes that a set of agents are collaborating to gain the benefit of sharing resources, but this sort of things tends not to work for one global comunity including very diverse people, like teens and libraries. I have not seen systems which make communities first class objects with explict commitment and membership.
HT: LOCKSS assumes that noone is doing the sybil attack and reducing the value
<Noah> Mentioning Oceanstore (http://oceanstore.cs.berkeley.edu/). Seems similar insofar as it's (I think) a giant peer-to-peer store in the sky, similar in that it has some sort of Byzantine agreement rather than central admin, different (I think) in that it's not fundamentally a front end to the Web, but a store of its own. You know when you're putting things into Oceanstore. All this is based on my vague recollections of what I heard about the project.
HT: Last block problem is that most people who are downloading anything obscure are also downloading it. Most don't have all of the file you want. Not last chronologically, the last that completes the file for you.
... There is a solution based not on the blocks that you have, but on linear combinations
NM: It's spread spectrum for p2p
HT: There is no way to request a range from current cache implementations. It's in HTTP 1.1, but implementations don't (?)
... Could be useful to be able to query cache metadata.
SW: interesting concept for something that is meant to be transparent
TVR: Could be that there is no way to query what is in the cache
HT: No way to identify specific blocks within a file
TVR: Donkey (?) does use URNs for identifying blocks.
HT: eMule is similar
TVR: This has been working well for a few years
TimBL: HTTP URIs have an owner you can go back to, and this is useful. It would be nice to have a p2p system that supports the social system where people own URIS
TVR: It's possible for multiple versions of a resource to differ very slightly differently but by using the MD5 hash as a block identifier, you can still get the right block
NM: In certain contexts, MD5 is a tradeoff.
HT: p2p and HTTP get are both pull mechanisms. Should be able to have them cooperate.
... If blocks had names, then an HTTP get would be able to retrieve blocks.
... If it's not in the cache, the name must be able to let the cache locate the data necessary
... Could traditional caches be elaborated to switch into p2p mode for some set of names at least
... Need to be able to do the equivalent of virtual hosting to host things that you don't own. Looks like that is not currently possible because of NAT and port 80 limits
TVR: Could envisage a world where p2p is actually the way that the internet works.
HT: that is the way some people would like to see things develop
DanC: What about the point Tim raised about community
TVR: If you let the p2p graph technology do its thing, you get the caching for free
SW: We've gone quite deep
HT: One line left - Apache already have a module to convert HTTP get of very large files into p2p
dorchard joins by phone
TimBL: I've heard that there is an extension that will fall back to something like bit torrent for large files
HT: So not just a server side component but also needs a piece in the client too
<dorchard> what kind of protocol operation do they use to get chunks of the file?
TimBL: Assumption is that the only place to look for the missing pieces is the community of people who are also looking for the same stuff
... I'd be interested in solutions based on the hypertext graph
<timbl> Secifically, that if a n HTTP request fails then one can try the referer as a nexttry, for caching or seeding or metadaata leading to these.
SW: I'd like to go through the notes I had from discussing things with the TAG members.
SW: Technical Agenda - desire to get long standing issues finished.
... Big topics - extensibility and versioning, tag soup integration, mixed languages composition
... Semantic web, web services (one web or two), mobile,
... Comment on tag soup situation persisting could be damaging to the web/w3C. One way of addressing this might be a set of best practice guides, if authored quickly
... We will make things easier if there is a clear focus and direction
... is TAG role to get ahead of the game or clear up the issues left by work of other groups
... Last time, the AWWW was the 'drum beat' for TAG work. Is there another rec track item that could provide that again?
... Not clear that TAG findings have an impact. Are we being ignored?
<DanC_lap> thanks, stuart, for doing the rounds of calls.
SW: Should we be concensus driven, and is this barring us from being controversial?
HT: Don't remember being held up by the need for concensus
NM: Could be that more recently there has not been so much of an issue
SW: Like the consensus approach and thinks its viable for such a small group
... invites comments about TAG going forward
TVR: Want to see more findings and communicating what we do to a wider audience
NW: Would like to see more focus and is optimistic about how things may go
NM: We're much closer to having some happy goal than 2 years ago. Worth trying, but we shouldn't force a new goal where it's not ready to be done.
... If setting a big goal helps us get individual items done, that's great
... It's ok to be a bit ahead, or a bit behind, but shouldn't be too far
... We are the architecture group, and part of our role is to highlight architectural principles to people
... Should keep looking for architecture
HT: Hard to find out what the TAG is working on and why it's important
<DanC_lap> (re "what's hot", I'm interested in a 'planet tag' blog aggregator)
HT: There are two documents on which I'm blocked. Mode of operation has been to assign findings to specific people and the rest review. We should change to behaving more like a working group for at least some findings.
TVR: Agrees
NM: Agrees
Other people indicated agreement
DanC: Language evolution stuff is particularly interesting and appropriate for the TAG
<Noah> I think it's not just more links on our home page, I think we could do a home page that really is a gateway for people learning about Web architecture and about what we as a group do. It should be a destination that, for certain purposes, people seek out.
<Noah> Right now, I think it's a necessary evil to get through it on the way to some bit of information.
<Noah> Who knows, maybe there's a Web Arch web site as well as a Web Arch finding?
<Raman> The other problem in explaining TAG work is that thanks to our date-based URI scheme (which i dislike immensely) everything we do looks like it was done in 2001.
VQ: Need more help for people to find out what we are doing and what's important. We don't expect the entire community to be directly interested in our work. TAG is mainly focused on W3C working groups
<Raman> I actually got asked this with respect to the finding I authored last year for example -- gist: "this looks like something from 2001, "
VQ: Not sure what our public face should be and it involves work
<Noah> Raman, I think if we have the right Web site, fewer people will be looking at the URIs, and more will be working through, e.g. our page on naming or identifying things on the Web. That could give high level tuturial, with links to the finding in context. We could have a page on XML-related issues, etc.
VQ: We have too many individual issues open and it's hard to prioritise and then get the momentum for progress
<DanC_lap> (hmm... do I hear that the TAG wants to design a web site? oh my. let's make a rock band instead. the politics are simpler.)
VQ: Maybe it is time to look at another rec track document. Gives a single document whose progress can be followed.
DO: Lots of the comments were interesting and appropriate. I've been working on three findings currently. Hoping to finish two of those by the end of my TAG stint
... Would like the TAG to be slightly ahead and slightly behind in specific areas, as Noah said.
<Noah> I think I'm feeling the TAG should be somewhat ahead, perhaps significantly ahead on core architectural issues, generally "behind" in helping to notice the architectural implications gleaned from codifying good practice.
DO: Peer to peer, wireless etc, are potential areas where we could be a bit ahead. Doing some findings in more of a WG style is also a good idea.
... Some findings are potentially very large topics and so there are lots of ways to go with a finding. That can imply a very different audience for the finding.
... Leads to churn in documents as potential audience changes.
<DanC_lap> (another point, re wider and wider audiences, is that in an attempt to please everybody, the document becomes mediocre for everybody and excellent for noone)
DO: Need to get back into the mode of writing and reviewing more regularly
<dorchard> TAG blog -> TAG wiki :-)
TimBL: Endorse lots of the comments about getting the message out, Brochure + Blog could satisfy this kind of thing. Brochure why important, blog for what's hot
<DanC_lap> (I tried to get the TAG to use a wiki in the beginning. maybe the time is right now? I'd sure like to try semantic mediawiki)
TimBL: We used to work on classification of the issues. We seem to have lost that. Defining the relationships will also help us get on the same page.
... One of the most important things we do is to pull together the bits of work done within W3C and between W3C and OMA - Quilt analogy, but more than 2D
... It's time for work on the Semantic Web. Because it's more rigorously defined there is a stronger framework in which to ask and answer the questions.
... Socially, I find it difficult to know how much to push for things and how much to sit back. Actually, same for everyone.
... Think the group has worked well, and that that is likely to continue.
... Hope I can convince the group that if we do Semantic web, I can convince the group that semantic web is an important piece of work for the TAG
TVR: Would like to try and get a stucture/classification to help Stuart
<DanC_lap> break 'till xx:25
NM: Advocates continuing this discussion after a break, perhaps tomorrow.
<Stuart> Dave... if you are there joining the virtual room might be help full https://www.rooms.hp.com/attend/default.aspx?key=EHLACVJXJ5
<Stuart> Others.... you should be able to join too.
SW: Projects the issues list.
<DanC_lap> (TVR, I think your idea of talking about a table of contents for a document is a good one to mix into this discussion of the issues list)
SW: The issues list is long and it was hard to reconstruct the context. Took the dates of last discussion to try and identify those that were 'fallow'
TVR: Even as we look at the list, where things are marked as complete, we should review whether or not the results have been disseminated appropriately
... There are documents hanging around in findings, but no context.
TimBL: Is there some pointer to 'what should I read to find the best information on a particular topic'.
DanC: We've also had the situation where we had made a decision but that we knew we had not connected with the appropriate community
... What would be the desired outcome?
TVR: I'd like people to be able to find the information via, say, a Google search
DanC: Do you know how the community would formulate the query?
TVR: Not sure, but it seems that the TAG is the last place the community would look
NM: What about 'Architecture the Web Site'. More outreach. Maybe based on the AWWW document.
... If it were done well, could be every reason for the community to visit it.
TimBL: The DIG group web site and the WSRI web site could be linked. It's a new site so could take advice from the TAG.
NM: we should have a better web site for the TAG
... We should also have a site that is about the web architecture.
TimBL: Making our web presence Architecture not TAG is right.
TVR: We're coming at the same thing from two directions. We were talking about a compendium before the break and a site now. I view these as the same.
SW: Returning to the issues list, I also 'tagged' the items with 'themes'
TVR: Should we discuss the ones that are active?
SW: That's where I'm going. (Reviews the list and points out the catagorisation)
TimBL: Inactive in the list means what?
SW: We don't appear to have done anything substantial recently.
... It looks like new issues get a lot of discussion.
TVR: Also looks like older things sometimes morph into something else
TimBL: The AWWW document work helped us concentrate on getting the appropriate items moved on
TVR projects an editor buffer ready to create a table of contents to guide structure of TAG work
Group editing ensues
<dorchard> I don't see the doc :-(
NM: are we trying to make a TOC that would make sense to a reader, or a way to organise our work
TVR: The former
NM: It looks to me more like the latter. Readers need a different organisation
TimBL: I suspect that we'll find that the TOC this time around will look a lot like we had last time
... If we find that we can allocate section numbers from the existing AWWW then we should decide to do a version 2 of that document
NM: I agree.
HT: where is our defence of http the scheme fit?
... We have a draft finding called URN's and registries, which has become use http:.
TVR adds it to the section on Naming.
SW: Is there a major topic on applications?
NM: I agree
SW: That includes things like how to define URI spaces
TVR: There is a piece of this about making restful sites etc.
... We could do this based on some existing application, like one from Google where these things are considered during design.
NM: We seem don't seem to be saying anyting about futures here.
TVR: I disagree that all we are only talking about is the 'old web'. The same old issues apply to new usages
<dorchard> TAG needs to produce youTube videos?
<Stuart> http://www.youtube.com/watch?v=6gmP4nk0EOE&eurl=
TimBL: On the whiteboard I've tried out a way of organising topics algorithmically. It is the upper half of an n-dimensional matrix
DanC: It's a good QA check
TVR: where does security come up
DO: It comes up everywhere. People encode information in payload to ensure it's secure
<timbl> 1. URI
<timbl> 2 HTTP
<timbl> 2.1 HTTP URI
DanC: This cross cutting idea could be a way to deal with volume 2. Includes mobile, security, accessibility, internationalisation,
<timbl> etc
TVR adds a new section to the TOC
NM: Suggests that there is an opportunity to look at use cases
DanC: Can we include massive interactive on-line games
TVR e-mails the current view of the TOC to the TAG list
TVR: One way to slice this would be to use the cross cutting chapter as the applications chapter
... Could also pick a concrete application and discuss the issues in that context
... It's like turning it upside down.
SW: Can we place the issues into the TOC?
TVR: I'd be happy to try and do that
Placing issues within the TOC ensues
HT: We need to remember that for particular communities the issues we have are the most important things that they are worrying about
NM: Should we have sections that address concepts that people actually regularly use, like site, document etc.
TVR: I asked a question about whether we are dealing with dynamic applications. With Web 2.0, the retrieved representation changes over time - the 'loading ...' example for a page being created dynamically
HT: I found that there wasn't a term for the thing that the user agent represents and the user interacts with
RL points out that there are some definitions that are in the DI Glossary
HT: That could be useful, but these are things that need to be in the Web arch glossary
Group adds a number of independencies as cross cutting concerns.
DanC: I was thinking about agents for change and dampers on change as cross cutting concerns
SW: Can we get a list of those that are teetering on the brink of completion
<Raman> toc23.html is on the Web site, will need the readable bit set.
<Raman> DanC, could you set the perms bit?
<DanC_lap> will do...
SW: What do we do with the TOC next?
<DanC_lap> fyi, Raman , you can set the ACL yourself at http://www.w3.org/2001/tag/doc/toc23.html,access
RL: Hanging the issue list items into the toc seems like a good next step
<DanC_lap> there. it's 200 now.
TVR: How about Stuart and I working on proposals about where to hang the open, active issues within the TOC
<DanC_lap> ScribeNick: DanC_lap
<Rhys> http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
NM recaps history of "self-describing web" discussion in the TAG back to EDI 1.5years ago
NM: punch line: simple story about self-description...
... you always need some rules to interpret something...
... even with paper documents, there's the alphabet, left-to-right conventions, ...
... and that way, what the author intended gets conveyed. [?]
... then, focussing on the web, since communication is not just point-to-point, but where readers are encouraged to explore documents not written specifically to them...
... if the contents of the web aren't we labelled, we don't communicate well.
... Then I was talking with Dan, and he said "yes, that's the simple part, but the more interestinig bit is dynamically picking up new terms via URIs"
... so now... we could pick over the text, but perhaps it's better to review goals: what does "self-describing web" mean to various tag members?
... [something connected to xmlFunctions that I missed]
... then I heard from tim... [ rdf... owl ...]
... and one sense of self-describing web is to extract RDF from XML and HTML, a la GRDDL. [?]
DanC: there's (1) the case for standards, and (2) the story of how to introduce a new format, using widely-deployed html/http/uris + natural-language + programming languages
TimBL: we told a story in webarch about how to get from a URI thru the stack of specs, to what the URI refers to
replay:
[13:44] <timbl_> q+ to suggest that the self-descibing document is one part of the architecture story which is a mapping from URI to intehet. It is the part in which the representation relates to intent. What is specifically interesting is the way you can boostrap yourself into find the necessary stuff indirectly eg through namespace document lookup.
<Stuart> timbl queued to say "to suggest that the self-descibing document is one part of the architecture story which is a mapping from URI to intehet. It is the part in which the representation relates to intent. What is specifically interesting is the way you can boostrap yourself into find the necessary stuff indirectly eg through namespace document lookup."
DanC: the case for standards is shared between email and the Web, but email doesn't have the lookup mechanism for new MIME types, by design. IANA is _the_ registry of MIME types for email.
<Zakim> raman, you wanted to say that limit to machine readability/follow-your-nose -- not "communicate to human"
TimBL: the recursive bootstratp nature is the interesting bit
TVR: this stuff about communicating "the same thing" seems somewhat of a distraction from the self-describing web story; it brings in styling etc., for one thing
... the interesting bit is the dynamic software configuration stuff, so that you can deploy new stuff in the web and it "just works"
DO: the dynamic discovery is the interesting story to tell; let's not spend too much space/time on the static/shared background
[or something like that]
DO: I have heard a few examples/use cases of [darn; leaked out]. RDDL... [darn; missed examples; help?]
<Stuart> ex1: xml doc->namespace(s)->RDDL....
DO: perhaps contrast with stuff that's not self-describing, e.g. microformats. where do we look up class="fn" without a URI?
... another counter-example is some urn schemes, a la the urns/registries finding
<Zakim> ht_mit, you wanted to mention "follow your nose"
HT: I want this finding to explain "view source" (ack Tim Bray) and "follow your nose (ack DanC)
<timbl_> "View Source" is very much human beings lookng things up. "Follow your nose" is most often done by machines.
HT: this should answer in detail "what do I have to know ahead of time to look at the Oxaca weather report?"
... there are 3 things you need to be able to look up:
... (1) the charset from the Content-Type header, iso8859-1 or utf-8
HT notes complex discussion of definitive sources of charset info
SKW: is that stuck?
HT: well, I have seen some progress, but it's been a year since the last progress point, so maybe time to rethink
... this is 3023bis, replacing "there is no fragid semantics for XML" with a ref to XPointer, and capturing negotiations about charset
TimBL: and XML ids?
HT: XPointer refers to xml ids in a way that agrees with specs that have come later
NDW: XPointer says "if it's of type ID..." and the xml:id spec says "xml:id is of type ID", so the pieces fit
TimBL raises a deployment question/issue about xml:id ...
is there a last call comment or issues list item or something that captures the XBL2/xml:id thing, please?
aha... "163. Last call comments on XML Binding Language (XBL) 2.0"
<timbl_> | I have marked your request as a potential formal objection.
<timbl_> I doubt that it will come to that, but thank you for leaving the door
<timbl_> open. I will ask the WGs for whom I reviewed the document if they feel
<timbl_> strongly enough about the issue to make that objection.
ah... ok... "I haven't heard any compelling arguments why XBL should spell it "id"."
TVR: [missed... about xml:id and ID...]
TimBL: I gather the XBL implementors have a table, by namespace, of which attributes are of type ID
<Zakim> DanC_lap, you wanted to advocate more study of traditional theory of language, e.g. monotonicity
<Noah> I still think the hierarchical view is more important than we're admitting. It does, however, make things like XPointer very hard, because it presumably wants to use tree semantics blindly without really checking the semantics of the ancestors.
DanC: pass; I'll come back to that at a better time, perhaps
<timbl_> apparently IIRC the architecture was that the attr which had type ID was kept as afunction of element namespace, so svg would map to xml:id
<timbl_> but that set of people may not have implemented it
<Zakim> dorchard, you wanted to respond to Noah that there are some commonalities across failures.
DO: [missed some...] I think this points out a problem with the W3C process...
... by analogy, consider my company and weblogic server and some stuff layered on it...
... a customer wants the new stuff...
<Raman> for the record, we discovered the problem caused by xml:id not being present as we were going last call on XForms and writing test suites -- we suddenly discovered that we couldn't tell whether an id was an id when getting xml instances from foreign namespaces
DO: [missed some]... so what you do is decide to be a platform provider, so you hold off on the layered stuff until the platform is ready
tx, Raman ; I was having trouble scribing.
<Zakim> DanC_lap, you wanted to advocate using CR to do 2-phase commit to sync dependencies
DanC: e.g. perhaps we should have held XML 1.1 at CR until XML Schema and XML 1.1 were better integrated
NM: consider a container format like SOAP...
... oops; putting 2 existing documents in one might introduce ID clashes
... on the one hand, it would be nice to have XMLFunction-style opaque boundaries around parts of the tree; on the other hand, that makes XPointer ID implementation impractical.
<dorchard> Any modularity spec, like xinclude, wsd:include, etc. have the same ID clash problem.
NM: I stipulate namespaces doesn't fix the SOAP combination problem. [?]
TVR: yes, which is why XML Core created xml:id
<timbl_> (that doesn't help the container problem)
HT: one of the reasons [this draft] is very limited, is that it's _only_ about getting at the infoset, not at only higher level app semantics...
... I'm concerned that you read the document otherwise.
... control goes top-down, but composition is bottom up. [he said it better than that]
... quoting interacts OK with id in the story I told, since quoting [bleah. what he said made sense, but it has leaked out.]
... and I like the limited "elaborated infoset" scope
some groaning about not going further...
TVR: if we can capture that much, it's a valuable contribution
<Zakim> timbl_, you wanted to note has just made a good case for the LackOfQuotingInXML-nnn issue
TBL: this points out a limitaion of XML, that you can't nest XML documents arbitrarily
... if there's a duplicate id, what does #theid refer to?
HT: the 1st one. the spec is subtle but clear
HT reads from a spec; scribe requests a pointer/excerpt
HT: note XML Schema has a scoped identity constraint mechanism
(I wonder if XPointer supports it)
NM: the tough point is integrating XPointer with those constraints
<Zakim> Noah, you wanted to say I >want< XML functions to be about semantics
NM: OK, so the scope of the draft is more clear to me now. thanks.
<ht_mit> NM, DC -- no, XPointer does _not_ currently offer any way of pointing to things courtesy of their XML Schema-assigned Identities
NM: but 90% of the time, the right way to design XML languages is to exploit the hierarchy in the applicaiton semantics
... [NM exceeds scribe's bandwidth, approaches timbl-speed ;-]
<Raman> added elaborating infoset to language section of toc23
NM: I think telling the recursive semantics story is a very interesting goal.
<timbl_> xml:quote="true"
<Noah> Why bother to namespace qualify quote? :-)
<Noah> In the interest of trying to help the scribe, what I said (or tried to say) was:
TimBL: I'm interested in looking at the costs and benefits of using xml:id in XBL2, both at the XBL2 scope and in a wider scope
<Zakim> Norm, you wanted to point out unforseen uses
<Noah> I understand that there is value in doing what Henry says he's done, which is to push out the easy part of the story first. That's Infoset elaboration. Fine.
<Noah> On the other hand, I think the 90/10 case should be that the semantics of the XML document should be recursive. I think that's a really, really interesting story to tell, and particularly important to my view of self-describing Web.
<Noah> Use case: a word processor application with persistent undo. The user edits the document, and a it changes, the word processor stores in a subtree in its XML file fragments of the XML that it will need to restore iff the users issues an "undo".
<Noah> To understand that the deleted content is not logically in the document, you have to recursively understand the semantics of first the root element, then the children, down to the one that says <savedUndoStuff>, which will tell you the implications of having that content there.
<Noah> Let's admit that generalized features like XPointer are unlikely to respect that, but the recursive semantics are crucially important to the self describing web.
<Noah> Bottom line: I hope Henry won't stop with the self-elaborating infoset, but will go all the way to recursive semantics of XML documents.
<Noah> We now rejoin our regularly scheduled xml:id debate.
TVR: the questions I'd look at: Is XBL2 designed as an XML family language for use not only in browsers, or...
... is it just for browsers and just happens to use angle brackets
NM: do you see it as black-and-white? or are there degrees?
TVR: well, I can see grey areas, but I see a pretty important black-and-white question.
Rhys: I bet it depends on who you ask. If you ask the XBL authors, they'll answer that it's just for browsers, but if you ask others, e.g. DI WG, they'll say they want to integrate it with other XML stuff
<Zakim> timbl_, you wanted to say: I think XBL2 is a generic XML langauge in the sense that it is in XML and will be edited and fetched, but it isn'y in the sense that it doesn't have
TBL: yes, in some ways XBL2 is generic XBL. They're not applying for a mime type, ...
... because it's not the sort of thing you'd attach in a mail message or follow a link to, except links when the context is clear. [!]
TVR: then why does CSS have a mime type?
TimBL: to distinguish it from, e.g. XSLT, in HTTP conneg
... everything needs a mime type; the XBL2 folks are happy using a generic XML mime type, since they don't expect dedicated viewers
DanC: the practicing community doesn't know that CSS has a mime type; 99.99% of it is served as text/plain, I think.
... and it still works.
TVR: see earlier discussion of outreach/communication/presentation of TAG output
<Noah> Well, if generic tools like Google search did something truly valuable with CSS that's correctly typed, and not with other CSS, we'd start seeing people take the trouble to type the content.
<Zakim> DanC_lap, you wanted to point out untested hooks are evil
DanC: so doing a mime type for XBL2 without implementation experience seems iffy
NDW: doesn't webarch say "you should get a MIME type"?
DO: in a couple WGs, the *only* reason we did a MIME type is so we could say how fragids work.
[that seems like a plenty good reason...
scribe: I was afraid you were going to say "the only reason we got a mime type was cuz webarch said we should"]
NM: [missed... something about +xml ...]. Maybe application/xml + namespaces is enough in lots of cases
TVR: yes, we should work on this mess around namespaces, mime types, and profiles
<Zakim> dorchard, you wanted to re-emphasize the point about self-describing in media types.
DO: yes, about this self-describing web stuff... as TVR says, it's pretty broken...
... e.g. I wonder how much better things would be if the SOAP media type had more richness to it.
<Stuart> hmmmm.... a media type param with a URI for what is wrappped?
DO: e.g. application/purchase-order+soap [?]
... so yes, let's work on this area
TVR: DO just covered one half/part; another part is CDF: how does it combine components using different media types?
<timbl_> <> a PurchaseOrder. PruchaseOrder rdfs:ubClassOf SoapDocument. SoapDocumnt rdfs:subClassOf XMLDocument. XMLDocument subvclasOf TextDocument.
<Zakim> DanC_lap, you wanted to inform stuart that I tried a mime type that delegates to URI space, but the IETF reviewer declined it
TVR: to see what's in a document... how much is in the mime type label vs buried in namespaces
<timbl_> TextDocument rdfs:subClassOf OctetSequence.
-> http://www.w3.org/2001/tag/doc/elabInfoset.html The elaborated infoset: A proposal Henry S. Thompson 30 Jan 2007
(hmm. the semi-formalism in the infoset spec bugs me. Now that we have XQuery and RDF specs with lots of running code and test suites, can we please use one of them?)
HT summarizes discussion history and abstracts the document
HT: is this an accurate summary of what we talked about last time?
... and is this the right enumeration of enumerating namespaces? there are 3: include, encrypt, signature
TVR: what about iframe?
TimBL: I'm concerned with "before any application-specific processing is attempted"
... I think the TAG issue is about all semantics, not just infoset semantics
... I much prefer the 2nd phrasing: "if an author takes responsibility for the information in an XML document, exactly what is s/he taking responsibility for?"
... xinclude is nice in that you can express it as a function of *only* the infoset, but that's a special case. iframe's semantics include manipulating pixels
TVR: only pixels? there's DOM stuff too...
TimBL: umm.... is the iframe actually replaced in the DOM? isn't there a separate DOM?
TVR: anyway, xinclude isn't that different from iframe, is it?
TimBL: xinclude can be expressed purely as an infoset manipulation; iframe cannot
<timbl_> if an author takes responsibility for the information in an XML document, exactly what is s/he taking responsibility for?
NM: I still have concerns about attaching elaborating semantics to namespaces. I prefer to use elements as the hook.
... i.e. qualified names
<timbl_> I agree with NM anout that that tit should be 'elaborating elements' not 'elborating namespaces'
HT: I think it would be a strange design to have an elaborating element in a namespace along with other stuff.
... the signals are still elements and attributes...
NM: then it's over-determined to attach semantics to namespaces
HT: I could maybe go either way; my preference is as written
<timbl_> TBL agrees with NM
NM: the reason I think this is more than a coin-flip is that communities like NVDL are giving semantics to namespaces, and I'd rather not endorse that
<Zakim> Norm, you wanted to ask if Tim means that a new spec should assert that it belongs to the "top down, self-describing" class.
TBL: no, I mean for it to apply to all XML
NDW: that's false; witness XSLT
... literal result element
TimBL explains how to look at the XSLT literal result example as an HTML document that has an elaborating gizmo in the paragraph, which elaborates to an em
NM: the HTML spec says that this is a document with a paragraph with an ignored thingy in it...
... or maybe it depends on the media type
TimBL: there's an error recovery view of it, but the <xsl:value-of > element has a qualified name...
<Zakim> DanC_lap, you wanted to note this sort of detailed design critique sounds like a "yes" answer to HT's question of whether he's in the right ballpark and to ask that we consider a
<Noah> Right. What I'm saying is, there are two general architectures to choose from: I) A namespace is (roughly) a collection of names, each of which has whatever semantics. Often, but not necessarily, the names from a given namespace are designed to be used together. -or- II) namespaces have a semantic, or at least, you've got to signal in advance which namespaces have the characteristic that some of their names are used in ways that carry unusual semantics (e.
TimBL: indeed, a <script> that sticks an h1 outside its part of the tree is not a function; it's a procedure with side effects
<Noah> I strongly favor (I), and I'm concerned that the draft finding on elaborating infosets is not the only place I see people making assumption (II). Possible future TAG work merited?
TBL modifies the html literal result element, so that it's a purchase order document...
scribe: unlike p, whose spec tells you [something1],
(scribe is struggling; if this were a WG design discussion, I'd interrupt to make sure we get this example in the test suite. but we're not, so I won't.)
HT: yes, I'm willing to try taking "elaborating namespaces" out. I don't think "namespaces have semantics "is broken but it's not a battle I want to pick.
... while I stipulate to Norm's point that non-compositional XML languages are possible, Tim's position appeals to my experience that people seem to almost always make compositional languages
... I presented a compositional explanation of SVG etc, and I got an "oh no; that doesn't work" at the backplane workshop
TBL points out some issue about XBL/SVG or something. [help?]
HT: I heard [Chris?] say "there is no domain in which you can model the semantics of HTML/CSS/SVG in a compositional way"
... I'm not certain I understand the argument, but his experience is considerable
<timbl_> I think tere may be cases when my idea of the 'semantic may be less concrete than Henry's, Maybe be parameterized by say window width say.
<Noah> scribenick: noah
HT: Can we wrap by popping to metaquestion: stipulate that I will remove the implication that namespaces have semantics, and will also make clear this is part of a larger and as yet incomplete project, which is whether all of XML is compositional.
SW: What's the larger goal not achieved?
HT: Doesn't say that in general, and strongly recommended in future, the application semantics of XML documents is/should be compositional.
DC: Can't you get there by deleting from this document?
HT: No. Well, result would be vacuous?
TBL: Have we said that the way to interpret the Namespace at the top?
HT: No.
NM: I hope Tim meant the qualified name of the root element.
TBL: Anyway, if we haven't said it's determined by what's at the top, we can't tell the story.
HT: Not convinced.
... In the strict story, XML documents get semantics via the Infoset. You don't interpret the angle brackets and equals signs directly.
... It's what's available via the Infoset.
... Thus, every statement about XML document must be in the following: "The semantics of an xml element namespace=x and localname=y is whatever.
... What this little document is addressing, except in odd cases like writing an editor, this talks about "the Infoset" you're starting with.
TBL: There's the mistake. There is not necessarily "an" Infoset. You recursively ask about the root.
... You can't in generally look through things and know when to do the elaboration.
HT: We fundamentally disagree. Never mind, we agree completely.
... There are probably two ways to understand this, mine is perhaps more naive but easier to communicate.
... I like to think in 3 steps. Each is functional, so you can compose them, and get the story.
TBL and NM: No, you can't get Tim's story.
HT: Step 1, parse character sequence to produce vanilla infoset. Step 2 elaborates, to get elaborate that infoset. Step 3 application semantics.
... What is semantics of <xi:include href="notMeButHim.hmtl"/>
... I think the semantics of the elaborated infoset.
<Stuart> is this depth first v breadth first?
TBL: Example of a document modeling pay per view. Scribe thinks there are two subtrees, one of which is guarded by a did you pay for it element?
... Whether to elaborate depends on whether user pays the money.
... Your model, Henry, involves picking up all the movies, and paying for them, first.
... In general, you have to do elaboration, to down.
HT: Taking that view gives you a more complicated model for no functional distinction.
<Rhys> ack :
<Zakim> :, you wanted to say that there is a real example of a markup language that does what TimBL just described
HT: What <quote> is for, is to keep the movies to be elaborated.
TBL: It's not just a quote.
HT: The reason you quote is because you're not ready to elaborate yet.
<Zakim> Noah, you wanted to talk about consistent use of certain QNames vs. prepass
<timbl_> NM: I think there is a coheernebt view of [,...] which make this work ... the spec sould say that one way o using xml:include is as a root element -- for example HTML could say that when xml:include is the root element then it should be elaborated.
<timbl_> TBL: If xml:include specifies that every xml:inckldue unstace in a document MSU be elborTED THEN THERE IS A BUG.
<timbl_> ooops
<timbl_> must be elaborated then there is a bug
NM: I think the spec for xi:include should say what it means as an application semantic if you use me as a root element and/or if my ancestor does not override my semantic
<Norm> timbl_, that *is* what the XInclude spec says
HT: I'm now convinced that Tim and I cannot for now be satisfied by the same design.
TVR: Try a new tack. Henry has spoken of pipelines and recursion. Let's consider, for comparison, LISP S expressions. When you write a recursive descent parser, you have two simple rules, which are to read head then tail of list, and a quoting mechanism to override the default.
... That's what appealed to me originally from Henry's design. The problem I have is that if we allow an element at some depth to change the quoting process, that's somewhat troubling.
... Feels weird to change how you're reading down the tree.
... Something from reading <a:foo> should not be allowed to change quoting characteristics of a descendent <b:foo>
RL: I think there may be real XML markups that would break if all XIncludes were pre-expanded. E.g. di:select, probably VoiceXML, and also probably SMIL.
... It has conditionals.
HT: Conditionals are a good example, because they are quoted.
... In the pure lambda calculus you have to quote with the only available mechanism which, perversely, is lambda.
... In LISP, as opposed to lambda calculus, COND has special characteristics. It's not a function, it's a "special form".
... The arguments are implicitly quoted, so we can decide to only evaluate some of them.
... What's true in Scheme, but not in Interlisp, the only special forms are built into the language. In Interlisp, you could define N-Lambdas (spelling?), in which you could define your own functions with implicit argument quoting.
... I'm arguing, by analogy, for the Schema-like approach.
... On this analogy, Tim's position would be the Interlisp position.
SW: Do we have enough to proceed?
NM: Well, we've crystalized a disagreement. :-)
HT: I suppose Tim and I need to think about who blinks first.
<DanC_lap> (I found http://www.lisp.org/HyperSpec/Body/glo_s.html#special_form ...)
<Norm> ScribeNick: Norm
<Noah> Workshop CFP URI: http://www.w3.org/2006/10/wos-ec-cfp.html
<Noah> Program: http://www.w3.org/2007/01/wos-ec-program.html
<Noah> Noah's TAG presentation: http://www.w3.org/2001/tag/2007/03/WSPresentation/titleSlide.html
Noah: Workshop attended by on the order of 50-70 people at Mitre in Bedford last week.
... Grew from an suggestion that W3C should concentrate more on Web Services and lesson SemWeb.
... Workshop was an effort by the W3C and the folks using WS for enterprise applications to find out what was happening, what was needed in this area.
DO: I think there was a focus on finding concrete use cases weren't being met by what's in play or expected to be in play.
<timbl_> I think the message from the AC meeting was more along the lines of: please have more focus and expertize on enterprise computing.
Noah: The call for papers was very heavy on use cases, but the actual talks didn't go in that direction.
... That may be the history, I'm just reporting what I heard Eric say.
... The main point is that Eric was pleasantly surprised by the response.
... Participants were a mix: vendors, WS-* usual suspects, a few REST supporters. Particularly interesting: there were a lot of regular users.
... Workshop would have been stronger if there had been more straight users.
... Big topics: what are people doing, what do people say they need, to what degree is the W3C the right place to do this, and looming behind, what is the relationship between the web and web services.
... So, what are people doing?
... WS-* is largely used behind the firewall for enterprise integration. Outside the firewall, it's REST based.
... Citigroup disagreed, saying they had a large investment in WS-* in public.
DO: Yahoo Mail uses SOAP generating several million messages a week.
Noah: Why are people using WS-*? Tooling was one answer. People perceive that when they buy in to the WS stack, the tooling grinds out a pile of code that does it.
... When they try REST, the tooling asks if they want to do a GET or a POST.
... The other highlight of something needed was better support for databinding.
... The tooling works well at first, but sometimes after several months you find bugs.
... One of the frustrations was that not everyone was present.
TV: The emphasis on the tooling generates second-order bugs (bugs in the tools generate buggy gorpy code). If you look at "w"eb "s"ervices, they're writing gorpy JavaScript by hand. There must be something better.
Noah: Tooling really doesn't really have anything to do with WS-* vs. REST. The choices are about the same.
... But the vendors have largly packaged it that way.
<DanC_lap> (fyi, I wrote an essay in April 1997 about this tooling stuff and distributed objects in the web... ". So one step forward in complexity management from richer interface description is two, three, or ten steps backward in total development cost." http://www.w3.org/People/Connolly/9703-web-apps-essay.html )
Noah: Paul Downey said it's about messaging. Messaging systems mitigate problems of "the connection dropped"
TV: Was there anyone asking about REST and JSON?
Noah: Yes, I think it was pretty well understood that there are these two approaches.
... The real deeper question is should WS go away because the web is simpler/better. Some say it should, some are not convinced.
... When I send a transaction to the Federal Reserve, I'm not sure I trust an http POST, I want to send it through a reliable messaging queue.
... Is W3C the right place?
... Some argued that the culture at W3C isn't right. Atom, for example, was done at IETF.
... Others pointed out the value of reputation, IP policy, staff, etc.
DanC: Atom wasn't low cost...Tim Bray's dedicated time for 18 months isn't cheap.
Noah: People repeatedly refered to the soap builders model.
... End points with test cases published quickly and a mailing list to discuss the answers.
... I thought it worked very well. And it helped the W3C WGs.
... One suggestion was to collapse the core specs into a single "WS Core" WG.
... Try to put a box around some of this stuff as sort of stable and just fix bugs.
... Ken Lasky produced some summary slides, but they don't stand alone. Hopefully he'll digest that a bit and post something.
... One position is that WS just isn't the web and you shouldn't try to join them.
... My view is that the web wasn't just built to integrate things that were designed to be integrated into it.
... That seemed to make some sense.
TV: Doesn't that dichotomy remind you of the xml:id vs id discussion of earlier?
Noah: We did eventually settle on a use case for our paper which I think really helped illustrate the points.
... I'd like to be able to get a link to my airline reservation but I'd also like to be able to send that to my travel agent and ask them to cancel it. That might require more than just http for security or whatever.
TV: We've had similar discussions around the mobile web. The biggest risk I see is that there's an increasing interest in carving out little disjoint spaces.
Noah: At the very least, there's a lot of buy in so that big systems will be built with it. So we should work with them to help tell the right stories.
DO: I have a bit of a different spin. I agree with a lot of what you said.
... I found a couple of points very interesting. The first was that for all the discussion of web arch vs. web services arch and how to reconcile them, there was little support for any kind of technical solutions that might do that.
... I pushed a little bit that perhaps WADL ought to be standardized at W3C. It barely made it onto the final ballot and there were only two votes for it.
... Including mine.
... And two votes against.
... I really expected one or two enterprise customers to be supportive, but that didn't happen.
... The flip side of that, allowing SOAP clients to bind to URIs, didn't even make it onto the ballot.
... The customers simply weren't interested in a technical solutions.
Noah: I thought the process was a bit bizarre. We had 15 or so things but we could only vote for two. So I think WADL is a good idea, but I put my two votes elsewhere.
... There was definite tension.
DO: I asked if the world was a better place because some of the specs had gone through the W3C?
... I said I wasn't so sure, cf the endpoint references debackle.
... There's tension between fast-tracking and having architectural coherence.
... If we don't want architectural oversight, maybe we should just do things at OASIS and rubber-stamp away.
... I also asked how is enterprise computing different from non-enterprise computing.
... In enterprise computing, the applications have more faith in the well-behavedness of applications.
... This means that they're more comfortable with more state in their applications.
... There are also issues around security, managability, and non-functional requirements.
... That raises questions about what that means for specs. There was little uptake on that.
Noah: Except that lots of folks said nice things about the state finding and encouraged us to finish it.
TV: There are very large scale applications available today that are much more robust than some enterprise apps.
... Apps like gmail have been exposed to far more users than most enterprise applications.
<DanC_lap> (the dev cost of gmail dwarfs meat-and-potatoes enterprise stuff, I expect.)
TV: When you talk enterprise apps, one important distinction is that you deploy a lot more enterprise applications. You get one app at GM and a very similar, but not quite the same, application at Ford.
DO: At a Yahoo search you might have eight different parameters with zillions of users.
... That means you can get away without a machine processable language.
... In enterprise computing, you have far more parameters but not as many users. So you need a lot more tooling support.
... The PeopleSoft application is something like 8,000 tables and 12,000 screens. You can't compare that to something like web search.
Noah: There are also things like reporting requirements, disaster recovery, etc. These folks are conservative.
... There's going to be a mix for a long time.
Stuart: Pick up tomorrow with namespaceDocument-8.
ADJOURNED