See also: IRC log, Minutes from Morning of 6 December, Minutes from Afternoon of 6 December
Resolution: Minutes are approved from Nov 22nd.
Resolution Tuesday 13th as normal
<Roy> regrets for 13th (ApacheCon)
Dan to scribe meeting on Tuesday 13th
Vincent: I adjusted the agenda yesterday based on discussion with Tim.
Moved two items to allow Dave to participate in the afternoon.
Dan: Move authoritative meta data to tomorrow to give us time to read.
Vincent, Lets move authoritative metadata to tomorrow morning.
Vincent: At that AC meeting, someone asked how our comments are taken into account by other bodies. The example of XRI was mentioned and it was not clear that it had a strong impact.
We should track more carefully the comments we send and track results.
<DanC_csail> (ah... perhaps URNsAndRgistries-50 is a better heading. hmm.)
Henry: 3.9 is on the agenda item where we should talk about that.
Vincent: ok, we'll add it to 3.9 (Tuesday afternoon).
Vincent: We should probably wait on this discussion as we have dates already for Feb/March and summery.
given that we have new members joining.
Dan: Should we commit to fall? Technical Plannery
Timbl: Tech Plannery is probably a resonable time.
<DanC_csail> HT: regrets for Fri of tech plenary
Current planned dates;
* Feb/March 2006, in conjunction with the Technical Plenary in France (resolved 14 June 2005), the afternoons of 27 February and 3 March (resolved 20 June 2005)
<DanC_csail> TBL: Sep conflicts with my usual holiday schedule
June 12-14 2006, Western Mass., USA, hosted by Norm (resolved 20 June 2005, confirmed 8 November 2005)
Vincent: We can discuss it as soon as we have our new members in early Jan.
Topic : Technical discussions
Issue schemeProtocols-49
Noah: produced draft finding at http://www.w3.org/2001/tag/doc/SchemeProtocols.html
Topic 3.2. Issues scheme Protocols-40
c /-40/-49/
Noah: Presents slides
<noah> Slides: http://www.w3.org/2001/tag/doc/SchemeProtocolsDec2005.pdf
also: Slides: http://www.w3.org/2001/tag/doc/SchemeProtocolsDec2005.ppt
Noah: I expressed some concerns that there was some confusion in this area.
Noah has re-written the finding over the last 5-6 months.
Hope to find three things;
1) Independant of exactly how I've written this, have some technical discussions around how protocols and schemes work and see if we can come to some consensus.
2) Do some review of what I've written (formatting aside)
3) allow ourselves the option that we not do a finding in this area.
Noah: This is one of THE key areas about the web where we are confused.
if you ask someone what DNS does, they give you a pretty good answer.
If you ask someone what a scheme does, they say it dictates protocols
Dan: and thats enough.
Timbl: I think a finding in this area is a good idea.
Noah: I think at least Dan and maybe others dont think we need a finding on this.
<DanC_csail> no, I didn't say "and that's enough"; I said it's pretty close; i.e. it's not different from the oversimplifcation of "DNS trades domain names for IP addresses"
Noah: I think this falls on a spectrum: A scheme to all quite loose and potentially late bound. To 'look in the privacy of your home you can do a lot of wacky things' and so doing anything other than doing HTTP with HPPT protocols is a wacky thing.
Noah: So I think there is confusion and thats why I wanted to do the finding.
Henry: I expected you to say the simple position is one in which the scheme and the protocol are one to one.
Noah: In laying out simply, I think people believe both extreams.
Noah: I think part of this is to clarify and point out the section of the documentation
I think one of the things we want to do is to say: For example, about that FTP over HTTP case, are you still in the web architecture or are we saying 'no, thats ok' and its still part of the web.
Dan: I think there are two FTP over HTTP cases. The one Noah wrote up and the one I think is coming.
Noah: The Tradeoffs slide is pointing out where I'm trying to go.
the scheme almost always gets them down to the fact that they get down to http 1.0 or 1.1
Roy: This is going in the wrong direction. Its associating a table of scheme names with a table it has in purpose of resolving the HTTP scheme.
Dan: It looks in the cache first.
Timbl: It looks int he proxy table first as well.
Dan: In the preferances you can point to a piece of java script to configure your proxy.
Henry: Yes, but that just fills the table.
<DanC_csail> that's a good story to tell in the finding; evolution of wais: from "scheme implies protocol" to proxy mapping
Noah: I think basically that there are a lot of important things happening.
Noah: When you put up an FTP server, you name it with an FTP scheme
Dan: Thats the right way to say it then.
Noah: This is written from the view of the client. If your offering the resource you should name it with the FTP scheme
Noah: I think in that same schenerio the user of that resource they tend to do that same 1:1 thing in reverse.
Dan: I think there is something deeper than that.
Henry: I'd like to go to the detail, its easier to talk about at the detail.
Timbl: The web arch is all about a URI and what it identifies and that is much more valuable and much more of a long term investment.
when we talk about evolution that we have a long-term commitment to that relationship.
Noah: I think the first schenerio is intended to highlight that.
Noah: Its interesting to me that the architecture document doesnt spell out that the relationship between the names and the 'things' is fundamental.
Timble: I dont think that is more broad that this finding.
Henry: I'd like to come back to an aspect of that, its not obvous to me that if I have an architecture resource and I want to mint a URI, then how do I mint a scheme
<DanC_csail> hmm... perhaps an interesting section for the finding... "I'm introducing an information resource [or something] to the web; how do I choose a scheme?"
Noah: One of the things I learned in June is that one of the scherios that you can get over time is that you may want to support the same resource with multiple protocols.
Where you have what you think as one resource, but you support it with multiple protocols. So if you believe the second bullet then you would have to publish it with multiple URI's
What I've tried to do is to seperate some things that are the general case.
What web architecture allows you to do and not to do.
<Roy> Most of my comments are at http://lists.w3.org/Archives/Public/www-tag/2005Dec/0000.html
Dan: Having rules telling you what your allowed to do seems ackward.
Timbl: The web arch permits you to do things.
<DanC_csail> ... since principle #1 of webarch is minimal constraint
Noah: I think we'll get there talking about specifics.
<timbl> You chose a scheme by its social arrangements (implied commitments, systems of authority, ownership, enforcement, etc) and its technical support (things you can get a representtain, there are concepts of contnt type or not, expiry, etc)
<DanC_csail> (yes! so let's talk about specifics! this is paaaaiiiinful!)
Noah: Rule#1 states that there is no constraint in the web. You can mix and match
Rule#2: You have an obligation to serve something faithfully.
<DanC_csail> (I don't think R2 is an architectural rule. I think https is a necessary evil; a non-architectural work-around of practical limitations)
Noah: lets say I send an ftp request over an HTTP protocol and the system knows enough then we should let it respond. But if you cant you need to return a 404 or something to say you cant do this.
Dan: I would like to go through the scenerios
Noah: I want to go through this first.
Henry: Lets finish the slides.
Dan: I was not heard correctly. I want to 'together pick one scenerio'.
Noah: I'm proposing also a rule#3 where the scheme can set expectations for integrity
Noah: So those are the rules as opposed the server as I've proposed them.
On the client, whats the rule that lets me write client software that allows me to do that.
Rule7: Its always safe to attempt access to any resource using any protocol.
Noah: Most of the time you may get a 404 back from the server if thats not ok. If there is a time when I'm violating the web arch, then you have to tell me where.
Roy: Thats not correct, look at your third bullet above.
<DanC_csail> (again, so we're discussing this?)
Noah: There is nothing a server can to to protect me from a compromised network or a spoofed machine. This is trying to say its safe except for that concern.
Roy: Somehwere you started out with the first paragraph with the relationship between the scheme and protocols
<DanC_csail> (my major point of order is, once again: I didn't expect a presentation. Noah sent his draft far enough in advance that we should start the discussion with the reviewers, not the writer.)
Roy: This is how you interpret schemes and how you would implement the protocols which is odd to me.
Noah: My point is that in building the browser, one of the major points I need to answer is choosing which DLL that may do something useful for you. But be careful about choosing protocols.
Roy: Thats a lot clearer than saying with a bunch of rules.
Noah: I dont doubt that for browsers thats common.
Noah: G4 - Serviing with protocol associated w/scheme is desirable, users expect this and supports dispatching on Scheme and you shouldnt read this finding otherwise
Noah: G5: Serve existing schemes with new protocols.
Noah: the issue is that by changing the scheme you would either need a new URI and put a pointer to the new page or you can continue to serve the new protocol with the old URI
Noah: Two methods. Do an http: request and get the results. The other method is two round trips, doing the http: request which dispatches the new protocol.
Timbl: couldnt you redirect.
Noah: sure, but thats two round trips.
Timbl: No a redirect states, no.. you shouldnt have used this one you should have used this one. Its operating like a name server.
Noah: Can you do this by media type?
Roy: yes.
Noah: ok, good point. We can also put that redirect media in.
<Roy> and the Upgrade header field of HTTP/1.1
Noah: We're two bullets away from being done.
G4: not all schemes are quite the same. Where possible, you should support the HTTP scheme.
<DanC_csail> (tbl seems to say semweb statements work differently with 301 and 302. I find that appealing... I'd like to try to write it in N3 rules and see if tim still agrees.)
Gener user agent guidelines
<Roy> http://www.iana.org/assignments/http-upgrade-tokens
Heuristic: G* choose protocol based on scheme
G9 its the user end thats responsible for not choosing an untrustworth protocols.
<DanC_csail> I think the rule is: for http: uri, if you use HTTP, the community endroses the result. If you do something else (e.g. a cache) you do so at your own risk.
Henry: I'd like to talk about the FTP schenerio
Henry: Specifically the one in Noah's report.
Dan: I'd like to talk about a differant one.
Henry: I've done some homework, the only way this can arrise is when you have a proxy.
<Roy> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42
Henry: It seems that this is a general story and its not, its a proxy story. The only time your supposed to send a get to an address with an absolute URI is when its a proxy.
Noah: I think what your saying is that there needs to be a proxy in the proxygateway, but would be an error if there is a hard-drive on this server.
Dan: A proxy is one who acts on behalf of somebody.
Timbl; it acts both ways, acts on behalf of the client to the server and to the server for the client.
<scribe finds it difficult to note finger points at the screen>
Dan: Its a question of who trusts who
Timbl: they both have to trust each other.
Dan: In what case does the server trust the proxy?
Timbl: the proxy logs on as 'bill gates' but the proxy isnt really bill-gates
Dan, no.. then the user messes with the server.
Dan: The user/agent and Proxy/gateway is one trusted relationship.
Timbl: If you have trouble with FTP sites, then you can use a proxy.
Dan: Sure, so express your trust in our proxy and go at it.
Noah: Lets say that the same administrated entitiy ownes both.
Then after a while I say, you know.. I can write software that can do both.
Noah: My finding says that thats ok, because nobody from the outside can tell the differance.
Dan: No..
Noah: I think there needs to be two answers, one for HTTP protocols in particular and I'm hearing maybe not.
Noah: or might it be ok for some other protocol on the web.
Dan: I dont think it has anything to do with the specific protocol.
Henry: The social implication of calling it a proxy is that it should be a general purpose and you've changed this to be your specific purpose, not general purpose.
Noah: You cant tell the differance from the outside.
Noah: So if that software is collapsed onto one machine, but they run seperatly then thats ok?
Dan: I'm saying that if you follow the protocols than its endorsed by this community.
Timbl: the web arch defines scheme names and so when your defining a scheme name you do it for certain social features as well as technical features.
If your going to define a new stack or new protocol you need to provide the same social features as well as technical features.
under technical features there are things like richness of the space and security
<Roy> I wrote my own version of this finding in 1995
differant spaces are very differant.
<Roy> http://gbiv.com/protocols/uri/drafts/draft-ietf-uri-roy-urn-urc-00.txt
Noah: The rule that was intended to cover that is this one (R2)
Timbl: Yes, I do accept that. But I think you talk about server space and security/integrety but there is a long list of additional things (like delays etc). The technical architecture must set forth expectations that they need to meet.
How the namespace is controlled and how I get one etc.
<DanC_csail> (scanning draft-ietf-uri-roy-urn-urc-00, the relevance doesn't jump out at me.)
Noah: In practice those things will come from the protocol. When I invent a new scheme, If those expectations get very elaborate or very specific then there may be only one protocol which meets all those things.
Timbl: no, thats not what I'm saying.
<Roy> (section 6.1)
Noah: your saying no it can go way beyond that. I'm suprised because the whole notion of operations..
Timbl: You mentioned on HTTPS there is a notion that it should be secure.
Dan: Can we zoom back into the FTP schenerio?
Timbl: Its perfically acceptable to use HTTP to implement FTP.
Dan: This makes sense to me, but you'd have to get that documented as a community consensus.
Dan: If you did FTP and it returned bits a court would support it, if you used HTTP transtaions to return FTP bits then people could say your proxy is messed up.
Noah: My finding says that I as the provider has to warrent that this is correct.
Dan: But it seems to me that we could tell a much simpler story.
Timbl: But one of the reasons why its always ok to use HTTP: is because/when FTP is rare.
Dan: But can you skip the gateway and go directly to the resource server, could you still use FTP
Roy: I think the answer is that you can do that if the user has given consent.
Dan: What I got out of this writeup is that there is some choice that the origan server is is making to say I'm using HTTP istead of FTP server.
Henry: So this is just a vanilla proxy story
Timbl: yeah, possibly.
Dan: Draws on the board: < d.phone -> HTTP -> Proxy.tmobile.com <-ftp->ftp.sf.net
Henry: But do be a proxy you have very specific rules you need to follow. I know this will work, regarless of what protocol you send, this will work. But where it gets interesting is that in the extream case where you run an http server which only responds to FTP servers from only my domain.
and In fact I'm only going to implmenet the security for my domain and the protocols for my domain, but I'm only going to deal in the port 80.
Its not clear to me that this is really a proxy.
Noah: What we're discussing is interesting, but its not related to my paper.
Dan: I know. But lets say that if Desktop.anywhere and does a get ftp:// but doesnt give proxy.t-mobile.com any money. They say its only for my customers but doesnt stop others from doing it, the it doesnt protect the social aspects.
<Roy> HTTP only standardizes transparent proxies -- it does recognize non-transparent proxies exist.
Timbl: Is it ok to use a differant protocol than that which has a differant name from the scheme name, and we're saying yes.
Henry: Yes, but only in very specific cercomstances.
Dan: So if you use a one word answer yes than that means that anyone can use anyone.
Timbl: Which is why yes, you need to preserve the social requiements as well.
Henry: I dont think this is a general story.
Dan: An ssh server only does tunneling and cannot change protocols
Noah: Henry, you said "I think its ok, to use an unnatural protocol to change schemes but only in limited schenerios"
Noah: I think the ones that are interesting are the ones which will come in the future.
I said watching for the ones that dont mix and match are certinly your responsibility.
Dan: this phone < http > proxy.t-mobile.com < ftp > ftp.snf.net
is worth writting up
Dan: If someone else hits proxy.tmovile.com without an agreement then they havent proposed a social contract.
Timble: ok, so https://bank.com < https > proxy.tmobile.com < http > dphone is an isuse.
Noah: So two things are wrong with this. 1) to serve faithfully which he's not and 2) in this particular case the bank shouldnt be trying
Noah: Your (the user) is responsible for knowing if the protocol is good enough.
Timbl: For example if you use a non-streaming protocol to something that needs to be streamed.
Noah: But if a user would rather get it without streaming then with nothing at all.
Henry: The problem I have with this is that it makes sweeping statements which are mostly only true with HTTP protocols.
Timbl: Your only talking about retrieving representations.
Henry: The finding states in 4.1.2 R2. Serve failthfully (see finding)
R/Henry/Noah/
Henry: its clear that serve is meant generaically and it may mean 'update'.
Timbl: In each scheme there are differant social and technical procedures which must be preserved.
Timbl: I dont like 'serve faithfully'
Timbl: For example: If we had an http: proxy server for mail and I'm going to do a post.
Dan: This is what I wanted to do.. I wanted to drill to one example and drill to a rule.
Noah: I was trying to find a large number of rules and boil them down to a few rules which are widely acceptable.
<Roy> Short rule: interaction must be faithful to what has been authorized by the resource owner
Timbl: I think there are a lot of words in this finding.. does it warrent so many words.
<DanC_csail> (we got thru a scenario to my satisfaction, but we didn't get to the fact that we learn.)
Timbl: There are some cases when you can use a differant protocol from the original protocol to access a resource.
Henry: By and large the answer is that schemes go with protocols, instead of switching it around and saying anything goes.
Noah: This is a guideline (4.2.1.g4) right?
Timbl: do you really want to argue that anything goes should be in there. Because I think there is a lot of push back in there.
<DanC_csail> 2nded: what HT said: start with "schemes go with protocols" and then explore what needs to be there for an exception
Noah: Yes, I think I do.. because in my Video idea example its much easier for the users.
Roy: The uri scheme discussion isnt there. This finding says that protocols are associated with URI schemes, whereas it should say that URIs are allocated to resources and, once allocated, the resource can be accessed via protocols that are consistent with the nature of that resource.
Roy: Once a resource is identified, any protocol that can faithfully interact with that resource can be used to access that URI scheme.
Henry: Thats related to the question I wanted to get back to.
<Roy> http://lists.w3.org/Archives/Public/www-tag/2005Dec/0000.html
Henry: The social and technical variences are because of the stated protocols.
Dan: we might have mis-phrased our feedback
Noah: I thought that what I listed here were the schenerios where we said 6 months ago were way too rigid.
Noah: So I wrote up the scenerio about it. Because its about the future.
Timbl: What you can do is look at the telephone scheme. based on the rotery dial, then based on the area code where you punch in the number of the area code but then there was an idea that the number took you to a particular telephone.
Then the phone numbers started to relate to a mobile phone, and now you can keep the number even if you change your phone, and late to even if you change your company.
so they made the space richer and more valuable by allowing you to keep your phone number (social aspect).
Noah: Yes, but it doesnt keep haning up and picking up (referance to redirect)
Timbl: Yes, but now you have text messaging etc.
Timbl: So the thing is morphing, and the web is morphing as well.
Noah: I think we have a meta question here. If we should spend some time on this. In some ways I'm feeling good about this discussion because I think its moving forward. However at this current course and speed we could spend the full two days on this topic.
Timbl: Well, you've received specific feedback and we need to accept that.
Noah: We'll, I'd like to go back and evaluate it before I accept it.
Noah: I think I'm hearing Tim say that changing protocols is important
<DanC_csail> 2nded: what HT said: start with "schemes go with protocols" and then explore what needs to be there for an exception
Timbl: I suggested evolution is import.
<timbl> ""There are some cases when you can use a differant protocol from the original protocol to access a resource."""
Noah: I'm still struggeling with this.
Noah: I have to go back to the first version I had because it tried to do that.
Henry: You covered a lot more ground on this, so we're not saying go back to the june draft.
Noah: Part of what I'm trying to do is cover the full spectrum.
Noah: Am I right in saying that the only time that you would see a differant scheme is when there is a two hop proxy thing here <referring to mobil phone sketch>
Henry: Its worth a footnot saying there are not really two stops.
Noah: I thought I heard Tim say its really important to allow that.
Henry: Http has a pecurlar status in this discussion. In general your not going to see that, when the protocol is HTTP the space is a bit wider.
Timbl: I think your trying to over generalize here. What you can do is to make an architecture where you mix and match things.
like going to the market and buying things or putting together lego blocks, because they're very differant.
<noah> Proposal (to be wordsmithed): "Mixing and matching protocols with schemes is not in all cases forbidden."
You only use a differant protocol when its fundamentally differant.
Timbl: What I just said is why I dont like the general statement.
Henry: What follows from the document the way you've written is that there is an expectation that there is a plausable plan that it should piggy back any other protocol.
Henry: And you dont want to go there.
Noah: i feel like now or sometime we need to go through that first scenerio.
<Zakim> DanC_csail, you wanted to ask to move discussion of "authoritative metadata" to tomorrow, by which time I expect to have read it and to suggest replacing R1 with re-iterating the
Noah: Moving to video example
examining approaches from draft finding;
Approach1
Noah: What if I have a video feed but I also offer a transcript
Noah: or in the worst case, I can serve it with mpeg or via http
Dan: We should zoom into that
Noah: I thought i had feedback that we should be very sensitive to all the existing links out there.
Henry: I think your approach 3 does that very satisfactory
Dan: So in this case (Scenario 1) its not completely obvious where I'd want all my links to be the same.
Henry: so I dont get that at all.
Dan: so its not 'today's vidio' its 'today's crash video.av1'
Timbl: I think Dan was going to say something else.
Dan: we used to be very sensitive to the fact that we didnt want to send everything to everybody so in fact the result is we just send mp3 files to everyone.
Noah: My guess is that what people will do in this example is that people will want to do real TV quality over the web.
Timbl: Are we aware of RTSP?
<Roy> http://www.rtsp.org/2001/faq.html
Timbl: could you actually call out FTFP in your discussion
Noah: I'd be glad to. I was thinking Approach 3 did that.
Timbl: Its easier to set yourself up to handle a mime type than a new URI.
Henry: what the application gets is the contents of the ram file, not the URI.
Henry: In approach 3,putting G6 in this example I strongly object to
Noah: This may have just been an editorial mess-up.. I think I put them in either or.
Timbl: I disagree with genralizing like that. (like approach 2).
Noah: See, I feel the need to generalize and I'm clearly getting pushback.
<Roy> RTP is the streaming protocol. RTSP is the variant of HTTP over UDP.
Timbl: Right.
<Roy> http://www.rtsp.org/2001/faq.html#HTTP
Noah: Its worth putting in general terms whatever can be said generally. I may be worth noting that there is very little that can be stated this way then.
Dan: I think we all agree we should say the most general say we can say and then dont go higher than that.
Noah: Ok, so I'm not sure then.
Dan: We've gone through two, lets do one more.
Timbl: There is an R7 that I object to. You can design an architecture in which a given protocol is used for a specific way (for example smtp could be used to 'explain') but, unless the whole community agrees its a wise thing to do then its an issue.
Noah: I agree its not worded the way I needed. What I was trying to say is that there is a sense in which its safe.
I don't understand how you can send an http: URI to an smtp server. . .,
Timbl: Its not enough to show that I have a system that works, its more important that the whole community agrees on how the protocol SHOULD work.
Tim is talking about sending 'EXPN timbl@w3.org', which is way weaker than any URI. . .
Noah: So I think your saying that my proposal suggests you can go willy nilly and do whatever you want.
Timbl: yes
Noah: What I'm trying to say is that when you have something that doesnt work, then its ok to switch protocols.
My point, again, is that as far as I know _only_ http has a mechanism for pushing an arbitrary URI to any server for any protocol other than http
Noah: I was trying to say 'the common casesses are common' but this is how you do the exceptions.
<Zakim> DanC_csail, you wanted to clarify "community endorses" and "user consent"
Dan: We need to keep this evolvable, and so we're going to put a few constraints in place as possible.
Dan: Schemes go with protocols is a better way to start the story (point1)
Timbl: When a scheme is created it generally supported by a new protocol.
<Roy> info is a grant that was spent before the clue was obtained
Dan: you can start with schemes start with protocols, but by the way, you can do a chache and why is that ok.
Also, when you say you said HTTP but you can use FTP.. and why is that ok.
Noah: I'll take the imput, I think I'm hearing I've gone too far and that I need to move back closer to where I was six months ago.
Noah: I'm learing a lot about the web as I'm doing this.
Henry: Since I found approach 3 very satisfactory if there is a scenario which makes it
Dan: I have an arguement against approach 3
Henry: The ram approach? I'd like to see that one.
Dan: Ok, so our two choices are <a href: "tagm.irc"#tagmem</a?> and irc, server, chan
Dan: And then someone else points to another tagmem on their pc, it may be a totally differant file because its local on my pc
Timbl: Henry's point then is that this is not what we do.
Noah: I think what approach 3 would say is that if these were going to become web resources then the IRC resource should source this with one URI and an aurhoritative source.
Henry: Dan, you did say you were going to explain the ram files.
I see you saying thats not true for irc files, but not for ram files
Noah: I thought it was implicite that you would forward to 'the link' and that there would be a URI and you would click it and an its in the HTTP scheme and there is only one of them.
Noah: The model is everytime you go to the resource, you go back to the original URI
Timbl: The primary reasons for doing this is because you dont know about HTTP redirection or the browser doesnt support it.
Noah: Just to capture this, Timbl is saying we can do this with redirects
and Dan is saying they can do this with irc files.
Dan: The clients are not starting to accept irc://irc.w3.com/tegmem instead of < a href 'ta... which is a good thing.
Noah: Why is this a god thing
Noah: In retrospect why shouldnt have been IRC server whatever, query string ? Irc channel.
Timbl: Because the social and technical aspects are almost totally seperated.
Timbl: The chat challen is more like an email address.
Noah: Ok, that sounds right.
Dan: Its hard to explain.
Henry: If you could, you wouldnt need the finding.
Noah: What I'm hearing is that schemes register information spaces and that they define the charactoristics of the things being named.
Timbl: You could slowly make IRC move to jabber, but it would be very difficult architecturally to make that change.
Henry: this is the first case that we have in front of us where a new URI scheme is generally regarded as a good thing.
Dan: when I read the IMAP spec I think why not HTTP.
Timbl: Then why shouldnt jabber be in the irc spec
Timbl: I'd like to get the upgrade of http to a pier to pier network.
<timbl> (peer to peer)
Noah: Now what I did with the pier to pier here (3.2)
<DanC_csail> ^ yeah, henry's point is interesting; I hope it makes it into the finding
Noah: Rule 1: Serving that HTTP space using any protocol is not in error.
Rule2: May peer-to-peer protocols have the characteristic that the content they serve is based on a distributed agreement amon those using the network.
Dan: I think we should split these into two scenerios
TimBl: I think we should focus on why this one is good.
Norm: I think we should at least point out why this may exist.
Norm: Read the second scenario because it says that sort of thing.
(3.3 Scenario)
Roy: this is a strange scenario
Timbl: In this case your going to be encrypting it and signing it.. I thought we were discussing 3.2
Noah: You mentioned checksums
Dan: But you talked about checksums and he talked about them in 3.3
Timbl: i'm not clear is 3.3 is talking about existing protocols or new protocols.
Noah: Both
Timbl: I think if its hypotentical then I dont see where checksums could not be used.
you want confidentially as well as integrity of data.
Noah: Thats not clear to me. That is impliciate as part of the scheme.
in practice HTTPS is almost always invoked with https protocol. Its supposed ot make it invisible to the guy in the middle.
Roy: There is no HTTPS protocol
Noah: I mean the protocol we run with the ssl.
Roy: it means http over a secure channel. Its primary purpose of the https is to make it hidden between viewers not to make it correct.
Dan: I'll disagree, but I'll wait my turn.
Noah: to say that something is secure means that you know something about the operations. Because your security a get or a put.
Roy: You have protocols that define resource. Those resources exist within namespaces of those protocols. THen you have desire to access those protocols withing that namespace and the quesiton is can you obtain access to resources in the old protocol with the new protocol.
Noah: But if I wrote software that wanted to do that by implementing a new protocol than your saying its a bad idea?
<Zakim> timbl, you wanted to answer why not HTTP
Roy: I'm not saying its prohibilited at all
Noah: Ok, I thought you were.
<Zakim> DanC_csail, you wanted to say I'm not sure https should have been a separate naming scheme from http; but to the extent that it is, it's to connect the //bank.com stuff to the PKI
Dan: R3 I'm not sure I buy into. There are differant ways you could have flagged to the client that they shouldnt have used clear text for this.
Timbl: This has all been examined from what a client or server should do.
Timbl but now what is appropriate for w3c working groups should do?
in firefox 3.2 and experimental system was stuck in, that when there was no response from the server a new HTTP request was put in the server.
timbl so when it got a successful dns but got a failed https then it would go back to the referring server and ask for the same page to get it from cache.
but then people realized this was only hitting 1/3 of the servers and other servers were being over-loaded
(future.. tentative discussion)..
so the new version comes out two years later with a true pier to pier version.
Dan: How does it preserve the property that the publisher gets to say what the right answer is.
Timbl: so when you do a hit to the original server, it will do a checksum.. so it would give you enough information.
<whiteboard discussion/drawings of above case>
Dan: So this argues that https doesnt need to be there.
Timbl: I may make sense that we keep the http protocol for this
Dan: last time we tried this it failed.
Dan: Put a check-sum next to the link and say dont do this in the clear
Timbl: so instead of putting the 's' in the https, put http:/secure/ in the url
Dan: It still gives it a distinct name.
Roy: They want o be able to dispach handlers based on the http name.
Timbl: Well, http could have just gotten bigger.
Roy: Well, yeah it could have..
Dan: The question was does it need to get a new name in order to get a peer to peer to be available.
Timbl: Its still http: its just that they have a new browser.
Henry: The work has been done. The information community has come up with a set of conventions with the checksum in the uri
Dan: We may want to cite that.
Timbl: What I'm trying to say is that we'll need to provide an fancy version of http in the future that can do this.
Vincent: I propose we close this topic for now.
Dan: I think we should try again sooner.
Noah: I can do this again quickly, yes, but I'm not sure if I can do it in two weeks.
Dan: So, how can we move this ahead again.
Noah: Its just going to take a little time to digest and re-write.
Ed: Can we do one part of at a time
Noah: I was trying to hit the sweet spot inbetween
Noah: There were some parts we didnt get to.
Dan: I want the scherio and rules together, its hard to see the scenerio before you can see the rule.
Noah: Thats been part of the challenge, last time I heard we were gong to need the scenerios first.
<DanC_csail> (I want a document that I can read from top to bottom)
Roy: Its unlikely that this will come up again before mid-january.
ACTION: Noah to produce new version of this document [recorded in http://www.w3.org/2005/12/05-tagmem-minutes.html#action01]
<Roy> on lunch break
<timbl> The assembled company agrees that this is a good question
<Norm> We resume at 13:30 EST
<scribe> scribe: Henry S Thompson
<scribe> scribeNick: ht_stata
VQ: what is the situation wrt Principle of Least Power -- was discussed when I was away
NW: Roy and I had an action to review Tim's discussion of this issue [PLP URL], which we did
<DanC_csail> walsh's review http://lists.w3.org/Archives/Public/www-tag/2005Aug/0006.html
http://www.w3.org/DesignIssues/Principles.html#PLP
DC: Should we raise an issue for this
VQ: OK, so we'll start with 3.2, Future Directions, then move to XML Versioning
TBL: At the AC meeting it seemed
clear, in discussion with VQ, that we needed to think about our
future directions
... Focus for next 12 months
... Gone from TAG responding to WGs and writing findings, to
TAG writing a document, to post-document accommodating new
members
... We could go back to doing findings, and then to V2 of
WebArch
<DanC_csail> oops; hang on dave
<DanC_csail> LOL! "hold on, dave, we'll be right with you", timbl says into the end of the cable ;-)
TBL: Or we could look in novel directions, e.g. follow up the possibility opened up by the httpRange-14 finding and look at the there's only one Web/SemWeb
TBL: Pleas at AC for help around Web Services -- provide answers to what they should do
<DanC_csail> (I didn't hear the help-with-ws requests as directed to the TAG)
TBL: Some people commented on the unfortunate demise of the Web Services Arch Group
DO: Wrt Web Services, TAG should
focus on aligning WSArch with WArch, helping making more WS
resources available for GET, e.g. via an EPR->URI mapping,
that would be good
... Doing something tactical like that makes more sense than
trying to do a big encompassing WSArch story, especially given
that so much of WS is being built elsewhere
<Zakim> DanC_csail, you wanted to think out loud if separating service-oriented-architecture from Web Architecture is more cost-effective than trying to smush them together
DC: Is there something the people who didn't play the first time would find compelling, perhaps turning around and talking about why SOA/WS is not the Web
DO: Well, I think WS and W are
both SOAs, but there's no consensus about wakes makes something
SOA
... My take is that SOA is just 'Learn the lessons of
distributed computing'
... In the absence of support for REST-style WS, e.g. from IBM
and MSoft, where does that leave the work on WS that are
RESTful?
... Would getting EPR->GET into Apache, would that be enough
to fix things, or at least start a move in the right
direction
NM: There are circumstances where
bringing WS into the Web is a good idea, but the WS
implementors I talk to aren't interested.
... Consider the WSRF cases, such as a URI for a disk
controller, and there's a parameter for the drive -- why does
it matter if I can't address each drive
... You say, what about content negotiation, maybe a disk drive
could produce a web page to describe its state
... They look at you like you're from some other planet. But
remember that you would have gotten the same response 10 years
ago wrt web servers in printers
... Parallel with SOAP via HTTP GET, that implementors see
insufficient demand to make it worth their time to
implement
DO: So what does that mean for TAG vis a vis WS?
NM: Bounded efforts to get things
straight, e.g. dialogue with EPR guys to improve the
situation
... Larger role to try to find ways of convincing that
community that this stuff is important and they should
care
... A bit concerned at making a big effort to produce something
that no-one is listening to
... Web page assembly using WS is one thing, actually
surfacing material only via WS is another
... Real value is when same resource is available via HTTP GET
and WS. . .
TBL: What's the advantage of exposing as a WS?
ER: It's easier to put the
business intelligence in the server that replies to the WS
request
... That determines the targetted marketing content
DC: Different from using lots of java?
ER: It's a software engineering
story -- much easier to design/develop/deploy
... Good synergy with developing content and info in XML
... Bridges mixed language working (.NET/Java/...)
DC: Complexity of these
development issues is that they don't make simple things simple
(GetStockQuote is not a GET)
... Bad because small devs do things completely differently
from big Enterprise shops
HST: Used to all be the same, but now Enterprise-level stuff has done what it always does
<DanC_csail> (what was that WS- portal thingy? and the corresponding JSR?)
NM: Interested in the addons, e.g. security beyond https?
<Zakim> DanC_csail, you wanted to say that our investigation of issue 47 seems productive to me; I don't see anything that would be much better than current tactics
ER: Not often
DC: issue 47 seems relevant here
<DanC_csail> DC: I'm happy with the way we're handling web services issues, e.g. endpoint refs 47. I'm learning from our discussions.
ER: I'd be happy if you could
just drop a WS into an HTML page and have it work
... We don't have web pages in HP anymore -- content blocks are
assembled via WebServices
... We feed our clients with HTML or XML
... If it's XML, it's either WSRP or text-oriented XML
RF: What you're describing is a
pretty standard portlet architecture, but it's pretty much
one-way
... The constrast is with JCR JSR170 -- Java Content
Repository, which is two-way
<Zakim> dorchard, you wanted to say that I don't think the issue 47 stuff will change more than .1% of web services deployed.
<DanC_csail> (no, I didn't say that, dave. I said our discussion of ep-47 is comfortable to me)
DO: DC said 47 is a good way to
help the WS group, but I don't think this is going to change
much if anything wrt deployed endpoints
... So in terms of effectiveness, not much joy here
... That's why I'd like to do a modest technical effort to
support converting EPRs to GETable URIs
TBL: So at risk of ratholing away from the strategic question -- EPRs aren't like RAM files, they're more like a little bit of metadata, like the head of an HTML document
<DanC_csail> ("ram file..." I wonder if that makes sense to DO)
<dorchard> I think that doing 47 is helpful to all of us in understanding, but at some point that needs to be tied to future directions.
<DanC_csail> I'm happy for that point to be not today ;-)
TBL: The reason you can't get a
consistent architectural story is because it's so functionally
unconstrained, you can do almost anything
... Should we do a Dirk and Nadia use WS?
HST: Only if it's xxxx
<dorchard> A thought experiment: A little bit of extra effort wrt HTTP Cookies and security might have helped put a lot more URIs out there.
<dorchard> Henry, I did do exactly Dirk/Nadia do WS in the state write-up.
<Norm> I certainly want us to be able to articulate that story
<DanC_csail> (sure, let's try to cook up something where we all agree that Web Services make sense. All the ones I see just cry out for using GET)
TBL: So maybe we do a Fheit to Celcius WS, where only the URI of the service is relevant, there's no URI for an individual conversion
ER: WS is for system--system
interaction, not for end user interactions
... We regenerate all our external-facing info regularly, using
WS internally
<dorchard> Dan, Henry: moderately lengthy state writeup with Web/Web service example is at http://lists.w3.org/Archives/Public/www-tag/2005Oct/0025.html
TBL: Imagining a biomed transformation pipeline where a number of steps to be gone through, no real interest in revisiting the steps wrt any particular instance, so no need for URIs. . .
<Zakim> noah, you wanted to question whether we should do Dirk and Nadia?
ER: Drop a WS on a web page
<dorchard> Dirk is tasked with making the banking application available as a Web
<dorchard> service rather than HTML pages. He uses XML, SOAP, WSDL, and
<dorchard> WS-Addressing to do this. The banking application is a service with an
<dorchard> interface containing two operations:log-in and getBalance.
<dorchard> From what I wrote up...
ER: Today you do an include, I want to have a Web Service there
DC: But include is a web service, seems to me
TBL: Doesn't use SOAP, so it's
not a Web Service
... ER wants an XHTML tag that does a service-side web-service
call
DO: One of the biggest thing that
troubled the WSArch group was this kind of question, did you
have to use SOAP? what about WSDL?
... WSArch never reached closure on this
ER: Should we tackle that, as the TAG?
DO: I did a Dirk and Nadia in my draft finding in October [ref. above]
<Zakim> noah, you wanted to talk about higher level features
<Norm> Thank you, dorchard. I had forgotten that you did that work, my apologies.
NM: Wrt Dirk and Nadia, the WS
community should be doing the primer for their own
technology
... Don't know how good a job they're doing on this, but we
certainly didn't do it for HTML or XML itself, . . .
<dorchard> Noah, the WS-A group is *not* doing a primer. MSFT/IBM/BEA/et al have not published a canonical WS-A Primer. That simply isn't being done.
NM: We should avoid doing their work for them
<DanC_csail> hmm... dave, 0025 seems to say "He uses XML, SOAP, WSDL, and WS-Addressing to do this." without saying why use SOAP
<dorchard> Dan, He uses SOAP because it's "good", his tools support it, and there's no reason not to?
NM: How does this stuff connect with the ways we know about getting value from the web, the semweb
<DanC_csail> there's lots of good reason not to use SOAP/PUT for "gimme my bank balance"; cf whenToUseGet-7 finding
NM: The interesting thing about the WS stack is that it tries to do much more than HTTP
<DanC_csail> his tools should support GET for "gimme my bank balance"
NM: For example, signing only parts of documents, using DSig
<dorchard> Dan, Dirk and his manager probably haven't read WTUG-7 finding.
<DanC_csail> I'm interested in trying to find a dirk/nadia story that shows *good reasons* to use SOAP. but 0025 is not one.
NM: So there's a continuum, from doing nothing you couldn't do with a GET, but you do a POST anyway, through using SOAP but not exploitign the headers, to the real rich use with security and so on in the headers
<DanC_csail> "because my manager is clueless about webarch" is not a good reason
TBL: I remember we decided not to
talk about what it means to be "on the web", or what an
architecture is
... The WSArch people didn't avoid that tarpit, which was part
of their problem
... It's really out of our sphere of expertise to try to solve
that problem
... We could try to spin off a taskforce, or get some of the
old WSArch group to try to do it
<DanC_csail> (I wish timbl hadn't provoked DO to remind us that we didn't define "on the web" against DO's advice.)
TBL: We only see to a certain,
limited, depth
... We could just say some things about EPRs and just leave it
at that
... Another point: [Guy from Verizon] pointed out this failure
mode in the WS story
<dorchard> "On the Web" problems in WS-A: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0086.html
<noah> Verizon's CTO appears to be Mark Wegleitner
TBL: Databases at the bottom, mixed IBM, Oracle, etc., WS interface, and his applications had WS interface on the back end, and there's a big WS box in the middle managing the connections
ER: There are several levels of content connectors in there
TBL: Big complex stack, application does a database read, converted to WS all the way down, converted back into a read at the last minute, but the caching and optimisation you used to get is gone
NM: Why can't you get the
optimization into the web services headers?
... This is just the old n-tier architectures, with WS instead
of DLLs/APIs
TBL: Different levels of abstraction
NM: Ad-hoc, caching if they were built-in by your consultant
ER produces useful n-tier WS picture [for the minutes]
<noah> HT: My view of the Dirk and Nadia story is: the WS community should do the basic primers. We the TAG should do the one that reminds us how to think about when WS is solving a problem that the Web wouldn't otherwise solve.
<noah> HT: The crucial part of my D&N story was when Nadia understood why having an EPR was better than having a URI for her purposes.
<noah> HT: I'm willing to stipulate that this story can be told, I've tried for the past month, but haven't succeeded yet.
<Zakim> dorchard, you wanted to say that not defining "on the web" was a mistake. WS-A really could have used that term
<noah> HT: Dave, your story is a good one, but it doesn't seem to be trying to solve me problem.
<noah> DO: Hmm, then maybe I didn't write clearly enough.
DO: The 'on the web' problem has indeed resurfaced
<timbl> I wonder whether we have an architectureal point about the levels of asbtraction
DO: as the WS Addressing tries to
come to term with our EPR feedback
... If 'on the web' was defined, they could say "Avoid EPRs for
resources which are 'on the web'"
<DanC_csail> [14:33] <dorchard> "On the Web" problems in WS-A: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0086.html
DO: Back to the finding I'm
working on, I guess I haven't gotten far enough, DC and HT have
given early feedback that it hasn't gone far enough
... I agree that the Dirk and Nadia story should get to the
point where it answers their questions ("Why SOAP"? and "Why
worth not having a URI?")
... I'm sorry there's no support for the TAG doing some
technical work on EPR->URI conversion
TBL: I didn't mean to push back, just no acceptance yet
NM: I wasn't pushing back on your suggestion at all
DO: WS powers that be are not writing a joint primer on EPRs and addressing, but it's all only happening in individual product documentation
HST: Yes, evidently, given responses to my first attempt at an example. . .
<Zakim> DanC_csail, you wanted to say that eventually, these enterprises are going to split/join, and the extent to which WS-* helps at *that* stage is the extent to which it deserves the
DO: Yes, I guess it must be in someone's interest that this doesn't exist, but I don't understand why
DC: I see that TBL's (and ER's)
diagrams are all inside the enterprise, so this stuff competes
with other large-info-system technologies
... but it's only once they go outside the enterprise that it
deserves being called Web Services
NM, others: Yeah, but a) the companies are balkanized and b) they're starting to reach these out beyond the enterprise
NM: grew out of old info integration problem
TBL: Mostly internal, some public though
HST: public ones are all one-way, info only, no action
NM: Not so, eBay virtual stores are managed via WS
TBL: [sketching on the board] httpRange-14 still needs work
NW: TBL and I have an action to do a Dirk and Nadia on this
<DanC_csail> fragmentInXML-28 is still open
HST: I want to hear about how our httpRange-14 decision interacts with fragIDs
TBL: So are we going to take that stuff, and pull it together into a new section of the Arch document
HST: I think doing that would be good, because just sending a two-para message to www-tag is a bit less that I expected for the resolution of such a long-standing thorny issue
TBL: No-one has implemented it yet
DC: SW Best Practices is now beavering away looking at the implications
<DanC_csail> DC: httpRange-14 is actually not capital-C-Closed; it's in "agreed; no reply from reviewer" state.
NM: Not clear what you're asking about epr-47 and httpRange-14?
TBL: Is the direction for the TAG that we aim to integrate stuff about them into AWWW, and then move on to more D&N about the SW
<DanC_csail> ACTION: TBL and NDW to write a draft of Nadia and Dirk first semantic web book [CONTINUES] [recorded in http://www.w3.org/2005/12/05-tagmem-minutes.html#action02]
NW: Yes, we should be doing V2 (epr-47) and V3 (httpRange-14 etc.)
TBL: I tried to sit down with Sanjiva Weerawarana, but I didn't come away with anything I can pin down
DC: Is it really the case that there's no consensus behind clarifying what WS really is
ER: I don't agree, I think they're trying
NW: They still think they can compete on this, so they're not trying
NM: But they all recognize the
interop is the key to success, so there is interest in a
coherent story
... Most of the reason for the lack of clean story is that
people are moving too fast to make that a priority
ER: WSRP is a counter-example, there's a lot of support for that and it's successful, standardized at OASIS
DC: Came from one of the members, or designed in the group?
ER: Believe it was done in the
group, in response to customer demand
... Took about 3 years
<DanC_csail> (looking stuff up... WSRP TC http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp )
VQ: WS and SW topics closed for now, as far as Future Directions are concerned
<dorchard> did we decide to do anything wrt WS?
DC: I'm content wrt process that
we haven't really closed the loops with reviewers, eg.
httpRange-14, and OASIS (xri), and WS-Addressing, and webcal:
(with Apple)
... and that we should put more energy into this
<Norm> dorchard, I said I thought WS and SemWeb were good targets
[break]
DO: I haven't had a chance to update the finding based on the discussion
DC: I can try to project the drawings in a way that DO can see as well
<DanC_csail> (dave, I'm gonna try to use violet (http://www.horstmann.com/violet/ ) in real-time in the meeting; if you can get it running on your display, you should be able to follow along by reloading)
<DanC_csail> ( I've got http://www.w3.org/2001/tag/2005/09/20-class-uml.violet loaded up; I'm about to project it)
<dorchard> (I have it up on the screen)
[HST introduces http://www.idealliance.org/xmlusa/05/call/xmlpapers/82.198/.82.html
DC: We didn't get very far with Term and Vocabulary
HST: What about 'style' and 'title' as names in XHTML -- they both name both element types and attributes
DC: Both uses of 'title' share a semantics -- they both function as short strings to identify things
TBL: What question are we trying to answer?
HST: Well, if you want to talk about versioning formally, you want to be able to say something, in RDF, along the lines of "the definition of the 'style' attribute changed from v2 to v3"
<DanC_csail> issues list points to http://www.w3.org/2001/tag/doc/versioning-20031003
HST: To say that, you need a URI which identifies "the definition of the 'style' attribute"
DC, TBL: So, you can't do that if you have a language which is promiscuous with names in the way XHTML is
<Norm> dorchard, can you paste the URI of the finding your referring to?
NW: Or you have to use non-simple URIs
DO: I discussed a range of possible approaches to doing this in the draft versioning finding
<Ed> more current version : http://www.w3.org/2001/tag/doc/versioning-20031116
<dorchard> Should be http://lists.w3.org/Archives/Public/www-tag/2004Nov/0071.html
<Vincent> I found http://lists.w3.org/Archives/Public/www-tag/2004Nov/att-0071/versioning-part1.html
<dorchard> Discussion on component version identification: http://lists.w3.org/Archives/Public/www-tag/2004Nov/att-0071/versioning-part1.html#ident
TBL: In talking about dc:title, in the context of versioning, you'd reify it, or use it as a string, and make assertions carefully framed by time of use and documents and so on
HST: [before this] Suppose I want to compare the definitions of xhtml:h2 in vNow and vNext, it would be useful to have URIs fopr each of those names
NM: Small changes in single name usages are worth talking about w/o invoking a heaviweight rev-the-whole-thing approach
<DanC_csail> (the XML schema versioning document sends firefox 1.5 on mac into the weeds! twice, now!)
NM: There are sometimes good reasons for wanting to be quite specific about names in versions
Looking at Section 8 of DO's draft
scribe: and section 8.1
DC: What's my motivation?
... Name in purchase order needs a middle name?
DO: Sure
DC: Who's Dirk and who's nadia?
DO: Dirk is the owner of the language
DC: Anyone dislike any of these?
NW: Yes, we think they're all bad, all existing stylesheets break
TBL: Reasonable to do this if you have a way of talking about the relationship between the two namespaces
DO: This is the UBL
approach
... We fed back to them that this is bad
NM: This could be understood as
pushback on the XSLT community to support this kind of
move
... Neither answer is clearly better in all cases
... Scale this up to a bigger language -- looking at the 2nd
example in 8.1 example 3
... Looks benign here, but if it were part of a larger system
with 2000 terms, I've now got a new namespace with 2001 terms,
2000 of which haven't changed
DO: I want to highlight Example 4, only new material goes into a new namespace
<noah> Dave's examples in section 8.2 refer to being "for each compatible version" --- which begs the question, what's the definition of "compatibility"?
<Zakim> ht_stata, you wanted to talk about the real UBL story
<Zakim> timbl_, you wanted to reiterate that our ability to handle extensions with new tags very much relieson having some compositional semantics of the language... if you don't know what
HST: UBL versioning actually do address the XSLT problem, by saying you should use type-based XPaths and type redefinition, so it all works
TBL: There's the future, when we
have XPath2 or meta-assertions about versioning, or we could
talk about the present
... What about saying, in an XML Schema, "back-compatible"
ER: Why do we need to be told we can ignore what we don't understand, if all we care about is first and last we just go with it
TBL: You can't be sure that the meaning of middle in v2 compromises the v1 interpretation of first and last
ER: We control versioning at 4
levels back-incompat, major and minor versions
... First two involve namespace changes
... May ignore is the default interpretation
<Zakim> DanC_csail, you wanted to ask about relating 8.1 to the violet/UML diagram
DC: Don't know how to relate this
to the diagram
... ubl1:first.xs:type=ubl1:firstType;
ubl2:first.xs:type=ubl2:firstType;
ubl2:firstType.base=ubl1:firstType
DO: The relationship is over in the Constraints area
<DanC_csail> (how does henry have time to follow UBL?!)
DO: My understanding of the UBL story is that major version changes must happen in synchrony
HST: I believe that's only for major changes
DO: I thought it was all changes
[scribe must fix record to make the above make sense]
<Zakim> noah, you wanted to talk about ignoring middle name
<Roy> http://www.pacificspirit.com/blog/2004/10/08/ubl_naming_extensibility_and_versioning_reviewed
NM: Talk about compatibility
http://www.idealliance.org/papers/dx_xml03/papers/04-04-04/04-04-04.html
scribe: Before you get to
versioning, the specs for a language tell you what Information
you get out of a document
... What we can now talk about is how we extract what we need
e.g. to extract the shipping address and printing the shipping
label
... Now we can look at the vulnerability of this process to
version-based changed
DC: Consumption is mediated by a Language, the same document can be in more than one Language
[scribe didn't get a diversion]
NM: We are talking in terms of a single Purchase Order Language
DC: The shipping-label-printer uses a different Language, just enough of the PO language to get at the shipping label
<dorchard> The UBL spec requires Namespaces names of minor releases to have "<name>-<major>.<non-zero>[.<revision>]". the <non-zero> part revs for every minor version.
NM: OK, I hadn't understood that
TBL: HTML1.1 and HTML1.2 had the same membership
NM: I understand DC to be saying that you could think about the table formatter as only caring about the TABLE-rooted sublanguage
DC: So now we can look at when the shipping-label-printer is or is not vulnerable to certain classes of versioning changes
NM: So each Consumer needs to make version-handling decisions consistent with their processing requirements
TBL: This is too
wishy-washy
... Can't we try to be more specific?
... Work towards subset relationships wrt meaning
<DanC_csail> (we're scheduled to recess at 5pm)
DC: Hope DO will be able to incorporate some of this
DO: Indeed, I hope to do that,
once I get some WS versioning use cases to the XML Schema WG,
then I'll turn to this
... Although state/eprs/etc. may get in the way
<scribe> ACTION: Dave Orchard to produce a new draft of his versioning finding by the end of the year [recorded in http://www.w3.org/2005/12/05-tagmem-minutes.html#action03]
<DanC_csail> This continues outstanding http://www.w3.org/2005/09/22-tagmem-minutes.html#action05 from Edinburgh: "DaveO and NM to continue and extrapolate the versioning work DO et al have been doing already, updating the terminology section"