See also: IRC log, Minutes from 5 December, Minutes from Morning of 6 December
Noah notes that, contrary to what he said before, he's at risk for the June meeting.
Draft finding from Norm: http://www.w3.org/2001/tag/doc/nsDocuments/
VQ: what's new in the draft?
NW: Rearranged some things. See section 3.
... New section 4 suggesting URIs for specific terms. This is partially in response to Paul Cotton.
... If the direction is broadly acceptable, I'm tempted to act on Paul C.'s suggestion to put back in schema examples.
... Will also flesh out lists of natures and purpose from RDDL
... I have incorporated comments from Ed Rice.
<Norm> http://lists.w3.org/Archives/Member/tag/2005Nov/0039.html
Comments from Ed: http://lists.w3.org/Archives/Member/tag/2005Nov/0039.html (W3C Member-only)
DC: Editorial?
ER: Yes, mostly.
NW: I did not act on Ed's suggestion to say "You SHOULD use choice X", as I didn't think we could get consensus.
ER: but why not a SHOULD?
... isn't it RDDL 2.0?
NW: RDDL 2.0 doesn't exist yet.
... We were going to pick that up. Time passed. RDDL 1.0 is out there.
ER: Is RDDL 2.0 dead?
<ht_stata> Extacting -> Extracting
NW: Not necessarily.
DC: We've been told by Michael Sperberg-McQueen that RDDL 1.0 misuses XLink simple links.
HT: I think I might disagree with Michael.
DC: Worth discussing in the finding? Probably not. Seems that reasonable people disagree.
HT: By the same reading, many uses of <html:a> are also misuses
... Norm, watch for "it's" vs "its".
DC: People will care about list of natures.
NW: Yes, I'm not assuming it will be right on first try.
DC: Adding to RDDL namespace?
NW: Hmm, good question.
HT: We could ask Jonathan Borden to do it for us.
NW: I can list all the existing ones, but not clear what to do for now about any new ones.
HT: The RDF relations should be in some other NS
... Maybe not, could go other way.
<DanC_csail> @prefix rddl: <http://www.w3.org/2005/11/rddl#> .
NW: I didn't mean to do that!
<DanC_csail> under "Here's an example of the DocBook model above, expressed in RDF using N3:"
NW: or, I could claim the prefixes aren't meaningful :-)
HT: I feel that http://www.w3.org/2005/11/rddl is OK for the two things where you've used it. I'm less convinced about the purposes.
DC: Which URIs are RDDL consumers using today?
Dave Orchard joins by phone.
HT: The rddl:nature and rddl:purpose as properly bound.
DC: How do you say "validation"?
HT: There's a rddl.org URI for validation, among other purposes.
... What are vendors like Microsoft doing?
NW: As far as I can tell, they are using the standard URIs as suggested above.
scribe notes: Norm is about to edit the draft in place...the specific version we're discussing is http://www.w3.org/2001/tag/doc/nsDocuments-2005-12-01/
HT: In my code, I do something broken. I just look for a nature which is the XML Schema namespace.
TBL: Are all natures namespaces?
HT: No some are, some aren't.
<ht_stata> http://www.rddl.org/
HT: Norm, please add a formal reference to N3. I was looking for one and couldn't find it.
<DanC_csail> (ref for N3: http://www.w3.org/DesignIssues/Notation3 is pretty good. it cites others that you might prefer)
<Norm> http://www.rddl.org/natures/
NW: Natures sometimes use media types, sometimes namespaces.
"When a referenced resource is not XML and its nature can be inferred from its MIME content-type, the nature of the referenced resource is obtained by appending the content-type to the prefix http://www.isi.edu/in-notes/iana/assignments/media-types/"
HT: The RDDL doc makes clear that it's the URI and not the referent of that URI that is a nature.
DC: misusing XLink?
HT: No, I don't think XLink defines role in a way that conflicts with this use.
DC: So, the only way to get two roles to be the same is to have their URI's spelled the same.
... Hmm, our conversion to RDF is probably wrong then. We should doublequote them in the N3.
NW: Ugh, that's really unconvenient. It inadvertently differs from RDDL.
HT: Looking at XLink spec...
<ht_stata> "The URI reference [the value of the 'role' attribute] identifies some resource that describes the intended property.
<ht_stata> http://www.w3.org/TR/xlink/#link-semantics
<ht_stata> So RDDL could be more precise about whether RDDL natures are namespace names or the resources they identify
NW: I'm not sure what best process is for adding new ones. What's the right relationship with Jonathan?
DC: We have a web registry.
HT: for purposes
NW: RDDL defines a namespace and some starting list of purposes.
... How to add isn't clear.
HT: Ours wouldn't dereference(?) into the RDDL spec as theirs now do.
DC: Nothing normative here?
NW: Right.
HT: I like that.
DC: Are we standardizing anything here?
HT: rddl:nature and rddl:purpose
... I'm talking about the predicate itself.
... We're standardizing that.
DC: If we're making one up, call it rdf:type.
HT: Did we discuss this before?
DC: Yes, but with no conclusion.
TBL: I don't think they're putting classes there.
HT: the issue is backward compatibility with what's already out there
<timbl> { ?X rddl:nature ?DOC } => { ?X a ?CLASS. ?CLASS rddl:ClassOfDocsOfNature ?DOC }
DC: would specification document be better than nature?
<timbl> { ?X rddl:nature ?DOC } => { ?X a [ rddl:ClassOfDocsOfNature ?DOC] }
<timbl> s/rddl/doc//
<timbl> { ?X doc:nature ?DOC } => { ?X a [ doc:ClassOfDocsOfNature ?DOC] }
HT: Norm has agreed that "rddl:" in my examples is an error
<DanC_csail> nsmeta:nature
HT: nature seems ok to me
... nsmeta:nature
... We might also want to do nsmeta:purpose.
TBL: purpose is the class of property, not an individual property.
DC: Thus, validation is of type purpose.
<DanC_csail> ('nsmeta' is ugly)
NM: What's the history of nsmeta?
HT: Just invented it, tentatively, to stand for "namespace meta".
... We have the outstanding issue of whether HTTP status code 200 or 303 is appropriate for retrieving namespace.
<ht_stata> It would be cleaner in principle if the NSURI identified the namespace, and the NS Document is what you get _via_ a 303 if you try to dereference the NSURI
<ht_stata> ... being a description of the resource, but not the resource itself
TBL: The namespace URI refers to the document.
NM: I don't think a namespace is a document. I think it is an information resource for which a document is an acceptable representation. Thus I can live with 200.
DC: I only want to use 303 for those namespaces in which people haven't put #
HT: The essence of the namespace is what names are in it and with what definitions.
... Most ns documents don't give all and only that information.
... Many NS docs don't have anchors
DC: The XML namespace does that.
TBL: you can't expect a machines to read the HTML spec.
NM: We've said that information resources are in principle completely representable in a message, but >not< that every representation need be complete.
NW: I think I have what I need to move forward. I will fix errors in examples and incorporate proper natures and purposes and produce a new draft.
DC: Jonathan Borden's been watching this discussion...let's find his mail.
<DanC_csail> ... he seems mostly happy. http://lists.w3.org/Archives/Public/www-tag/2005Dec/0021.html
<Norm> http://www.niso.org/news/releases/pr-InfoURI-11-05.html
Discussing press release: http://www.niso.org/news/releases/pr-InfoURI-11-05.html
DC: Review of history: (I) the TAG sent a critical review regarding the proposed XRI spec; (II) we've recently learned it's advancing at OASIS.
NW: The vote seems to have gone out, and is open through December.
DC: Their process seems to require them to consider our comments, but not respond to us.
OASIS discussion of TAG comments can be found in: http://lists.oasis-open.org/archives/xri/200511/msg00068.html .
<ht_stata> http://lists.oasis-open.org/archives/xri/200511/msg00068.html
<dorchard> BEA voted No on the XRI spec btw.
<DanC_csail> "Following is a first draft of the proposed accounting for public comments on
<DanC_csail> XRI Syntax 2.0 as required by section 3.4(g) of the OASIS TC process.
<DanC_csail> "
<dorchard> For historical purposes, we never answered an informal query from them as to how http: uris could do their use cases.
<DanC_csail> [[
<DanC_csail> In particular, the HTTP URI scheme did not (and could not) fulfill this
<DanC_csail> requirement because the vast majority of identifiers produced using this
<DanC_csail> scheme: a) are concrete identifiers (identifiers tied to a particular
<DanC_csail> domain, directory, application, or device), and b) have (by definition) a
<DanC_csail> specific method of interaction (HTTP).
<DanC_csail> ]]
TBL: They have a set of protocols.
HT: Is it obvious to those of us here why the http scheme wouldn't meet their needs?
<DanC_csail> requirement seems to be "consistent way of identifying resources independent
<DanC_csail> of domain, location, application, and interaction method."
[The XRI was chartered in January 2003 because, after considerable research,
its organizers concluded that no URI scheme, including the HTTP and URN
schemes, provided "the desired properties of identifiers and their relation
to resources" when the desired properties were those of uniform abstract
identification, i.e., a consistent way of identifying resources independent
of domain, location, application, and interaction method.
]
We want to change the protocol for our names, without changing for the rest of http names.
TBL: e.g. ISBN numbers are in here, and perhaps other things like RFIDs, and we'd like to use a better protocol later.
... playing devil's advocate, you will be able to change HTTP but it will take you 5 years.
NM: Doesn't this relate to our discussion yesterday of schemes and protocols? At least in the draft we reviewed yesterday, I made clear that some http scheme resources could be served with the protocol of your choice while others might be served with HTTP 1.1. The TAG does not have consensus on that, but I neither have we concluded otherwise.
DC: Does http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml say anything about this.
<Roy> http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01746.html
DC: Regarding the info scheme, IESG acknowledged dissent but decided to register it anyway.
HT: Yes, the registry has been updated, and refers to an internet draft.
DC: Earlier we expressed concern about URNs for naming media types. Mark Baker and I started writing a draft, but then we dropped it.
<ht_stata> Information Assets with Identifiers in Public Namespaces [RFC-vandesompel-info-uri-04.txt]
DC: Maybe we should call together in IETF IG meeting.
Some discussion of having a URI IG call to explore reasons why http does or doesn't solve the problem.
DC: Henry, do you feel your finding is in good shape?
HT: Not all the way, but as of yesterday I do know of at least one example of when a new scheme is justified (irc), and that will help me discuss the tradeoffs. Unfortunately, due to obligations to other WGs, don't look for another draft before Feb.
<Zakim> DanC_csail, you wanted to go over http://lists.w3.org/Archives/Public/www-tag/2005Apr/0076 "for names consisting of an adiminstrative hierarchy and a path, HTTP/DNS is as good as
<ht_stata> http://lists.w3.org/Archives/Public/www-tag/2005Apr/0076
DC: I think they believe that http scheme URIs are supposed to be dereferencable.
<DanC_csail> DC: our "A URI owner SHOULD provide representations of the resource it identifies" applies to all URIs
<DanC_csail> TBL: what about mailto:
<DanC_csail> ?
NM: That's backwards. It is a good thing on the Web if your resource is dereferencable. Naming with http helps you do that, but the converse isn't true: just because you name with xri doesn't mean you have less advantage from being derefencable.
HT: I wonder whether part of the concern is a misperception that with http scheme, you must start by interacting with the IP address returned by DNS for the identified authority.
<DaveO> I think we should show how their requirements can be met by http: URIs.
TBL: For example, you could go to info.org and find a registry (perhaps in RDF) who have copies of information for different (...scribe didn't catch this...)
NM: Is this an HTTP cache?
TBL: No
<DaveO> How about a Dirk/Nadia story for creating a "location independent" identifier?
DC: consider http://lib.info/n/1234 .
... Ordinary Web software gets either 401, not authorized or (???)
... However, we infer that client software can be deployed (or else how would the info scheme have been implemented?)
... Instead of hooking an "info" scheme handler, they periodically go to http://lib.info/n/meta?mit.edu , which returns 200, with license and information on redirection.
... Now I go back and ask for http://lib.info/n/1234 but I've learned to ask differently, probably with a credential or redirect determined form the directory returned from "meta".
NM: I still think that some people are going to say "Yes, but hooking on the scheme in a user agent is easier than making a chain of proxies, some for "info" some for "xxxx" some for the rest of the "web".
DC: Not sure that's the only concern. There seems to be some feeling that in general people have better control of their own worlds if they own a scheme.
HT: I think I have the input I need to move forward, but it will probably be Feb. before I have a revision.
We had agreed in Edinburgh that two changes were needed before an approved finding. See: http://www.w3.org/2001/tag/2005/09/22-tagmem-minutes.html#item06
<scribe> ACTION: Norm to apply changes to nameSpaceState-48 document and recirculate for comments [recorded in http://www.w3.org/2005/12/06-tagmem-irc]
Henry wrote a proposed use case, and Noah solicited comments from the public.
See Noah's note at http://lists.w3.org/Archives/Public/www-tag/2005Nov/0048.html and fairly long thread that follows.
Henry's use case: http://lists.w3.org/Archives/Public/www-tag/2005Nov/att-0008/eprExample.html
NM: Most of the feedback we got suggested that the use case in Henry's note is atypical. Though I'm not a WSA expert, I can try to sketch a few use cases that seem representative of what the email responses suggested.
[At this point Noah went to the board, and scribing happened only intermittently. The following two use cases are reconstructions made during editing of the minutes, but should be pretty close to what was outlined on the board. A few corrections have been added based on email reviews of earlier drafts of these minutes (see http://lists.w3.org/Archives/Public/www-tag/2005Dec/0079.html). Note that namespace declarations were not shown in the examples on the whiteboard, and they are not shown below. soap:, wsa:, wsaw:, etc. have the obvious bindings, and others are specific to the application.]
WSA Scenario 1: accessing a disk drive
This scenario consists of two SOAP round trips. In the first, the client makes a call to some service, and somewhere in the response message is an end point reference for a disk drive. In this example, there is a single disk controller for several drives; the EPR uses a URI to identify the controller, but a reference parameter for the drive number:
<soap:envelope>
<soap:body>
<m:replyMessage>
...
<drive>
<wsa:EndpointReference>
<wsa:Address>http://example.com/diskcontroller</wsa:Address>
<wsa:referenceParameter>
<d:driveNum>3</d:driveNum>
</wsa:referenceParameter>
</wsa:EndpointReference>
</drive>
...
</m:replyMessage>
</soap:body>
</soap:envelope>
After receiving this response, the client sends a second request. This time the EPR received above is used to address a message to disk drive 3, requesting that it take itself offline.
<soap:envelope>
<!-- the SOAP binding for EPRs turns ref parms into SOAP headers>
<soap:header>
<d:driveNum wsa:isReferenceParameter="true">3</d:driveNum>
</soap:header>
<soap:body>
<disk:goOffline/>
</soap:body>
</soap:envelope>
The above message is sent via HTTP POST to Request-URI "http://example.com/diskcontroller", as specified in the EPR. The SOAP header results from the binding of the reference parameter in the EPR.Except for this binding of reference parameters to headers, the EPR is opaque to the client.
WSA Scenario 2: order processing
In this scenario, a client sends a purchase request to a server. Processing of the order is expected to take several days, longer than the system can reliably keep open an HTTP connection. Therefore, the client provides a "wsa:ReplyTo" EPR, indicating an address to which the response to the order can be delivered:
<soap:envelope>
<soap:header>
<wsa:Replyto mustUnderstand="true">
<wsa:Address>http://example.com/orderingClient</wsa:Address>
<wsa:referenceParameter>
<d:orderRequestID>3</d:orderRequestID>
</wsa:referenceParameter>
</wsa:Replyto>
</soap:header>
<soap:body>
<po:purchaseOrder>
...details of order here...
</po:purchaseOrder>
</soap:body>
</soap:envelope>
The WSDL for the above request includes:
<wsaw:UsingAddressing wsdl:required="true"/>
attached as a child of the binding. UsingAddressing gives permission for constructs like ReplyTo to be used.
The server receiving the order uses SOAP header processing to determine that a delayed reply is expected. Accordingly, it confirms receipt of the request with an HTTP status code of 202. Later, when the order is complete, the results of order processing are POSTed as a separate HTTP request directed to the ReplyTo EPR. In this case, the Request-URI of the POST will be http://example.com/orderingClient and the message will have the form:
<soap:envelope>
<!-- the SOAP binding for EPRs turns ref parms into SOAP headers>
<soap:header>
<d:orderRequestID wsa:isReferenceParameter="true">3</d:orderRequestID>
</soap:header>
<soap:body>
<order:resultsOfOrderProcessing>
...details of order processing results here...
</order:resultsOfOrderProcessing>
</soap:body>
</soap:envelope>
The following IRC notes were taken by other TAG members while Noah was presenting the above scenarios at the white board:
<Norm> <useful-disk-drive xsi:type="eprtype">
<Norm> <wsa:Address>...</ws:address>
<Norm> <d:drivenumber>6</d:drivenumber>
<Norm> </useful-disk-drive>
<DaveO> In WS-A, there is a <wsaw:UsingAddressing/> extension that is attached to the binding as a child to indicate wsa
<Norm> HCF!
<Norm> Halt and catch fire
<DaveO> When echoing headers, the client must mark the header with an attribute indicating it was generated via the wsa processing model, I think it's "wsa:isReferenceParameter"
<DanC_csail> dave, this is rougly what's on the board http://pastebin.com/451392
<DanC_csail> can you see that?
<DanC_csail> rougly what's on the board http://pastebin.com/451392
<DanC_csail> reload to get syntax highlighting
<DanC_csail> daveo, note you can edit the pastebin entry, if you want us to see something different
<DanC_csail> version of 20:37 spells it wsaw:useingAddressing
<DanC_csail> sketch of order processing whiteboard bit http://pastebin.com/451401
<DaveO> <binding name="reservationSOAPBinding"
<DaveO> interface="tns:reservationInterface"
<DaveO> type="http://www.w3.org/2005/08/wsdl/soap12"
<DaveO> wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
<DaveO> <wsaw:UsingAddressing wsdl:required="true" />
<DaveO> <operation ref="tns:opCheckAvailability"
<DaveO> wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" />
<DaveO> <fault ref="tns:invalidDataFault" wsoap:code="soap:Sender" />
<DaveO> </binding>
<DaveO> From the editor's copy http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8#indicatinguse
<DanC_csail> rev 20:42 http://pastebin.com/451405
<DanC_csail> 20:43 http://pastebin.com/451410
<DaveO> this is really good and interactive
<DanC_csail> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 10.2.3 202 Accepted
DC: So with an EPR you wind up with this extensible detail, and then exploding it back into SOAP headers
TBL: The extensibility is important.
NM: Yes, I think so, but there's also the point that SOAP infrastructure to dispatch on SOAP headers and do mustUnderstand is widely deployed.
<Zakim> ht_stata, you wanted to relay Mark Baker's concern
DO: I want to emphasize that's crucial. That's probably the main reason people are excited about this stuff. Also the power of XML.
HT: Let's remind ourselves that the person who raised this issue (Mark Baker) wasn't concerned with any of this.
... One of Mark's concerns is that no Recommendation tells you to send to the <wsa:Address>.
DO: Consider multihop with HTTP first hop and JMS for second. Note that wsa:Address is for the ultimate destination, not the intermediate. Mark believes that HTTP prohibits this.
HT: Based on yesterday's discussion, the HTTP is a proxy and Mark is right.
TBL: What sort of addressing is done over non-HTTP links. MQSeries, say.
... Dave?
NM: Is there an HTTP hop there?
DO: Yes, sure HTTP is there.
... one way is that the [address] is the HTTP intermediary and the refParm tells you what to do.
... you don't need standard because refParms are OK
NM: Well, you could write a spec for a refParm
DO: Oh, I see, you mean something generic. I was thinking a particular customer would map the refParms into the queuing system.
<ht_stata> That reminds me of a crucial aspect of much of the pushback on my original example: The person who mints the EPR is the person who will decode the reference parameters in it at the end of the day
NM: Some queuing systems have URI schemes, and you could also put those in the [address]. Right?
DO: Right. Also, note these will be used a lot for session IDs, etc.
HT: So the majority case is, the person who mints the EPR is the one who decodes the parms.
NM: I've heard that in WSA there is some serious discussion about making our proposed text weaker.
<DaveO> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Dec/0029.html
NM: I certainly hope WSA is committed to showing us any counterproposals so we can try to get consensus before heading into the formal Rec submission.
DO: I think there's a good chance that will happen.
??: Do we have an answer for Mark Baker
<DaveO> I think it's the right thing for WS-A to ask.
NM: Based on a quick read, the text in the proposal at the bottom of http://lists.w3.org/Archives/Public/public-ws-addressing/2005Dec/0029.html looks fine to me.
Thank you to MIT for hosting.
VQ: The Dec. 5 & 6 F2F meeting of the TAG is adjourned.
<scribe> ACTION: Vincent to invite Mark Baker to future telcon to discuss his concern. [recorded in http://www.w3.org/2005/12/06-tagmem-irc]