RE: [uddi-spec] Comments on the use of fragment identifiers in the "Usin

Luc,

Having checked the 1.08 BP again, I agree that replacing MUST with SHOULD is in keeping with the wording in 1.08 so I have made the change. I also changed the MUST to SHOULD in Appendix C itself.
[LC] Thanks

Surely this does not require another 30-day review though? The TN has had a 30-day review and the only issues that were brought up were minor editorial ones with the exception of the issue that has become CR-032. I was hoping that, assuming CR-032 passes, I would make available one final version that had all the changes (including this fragment identifier change) applied and we would allow a week or so for people to check that the issues had been satisfactorily addressed and then we would vote to publish the TN. If we have to start another 30-day review every time we change a word we will never publish anything!
[LC] I apologize. I was under the impression that we hadn't called for a 30-day review yet (at least I hadn't). I went through my mail and found a reference to your mail of the 21 March (http://www.oasis-open.org/archives/uddi-spec/200303/msg00068.html) which coincided with the date I changed my email address and was dropped off the list for a while. I agree that we have observed the 30-day requirement and with your proposal. In short, no need to start another 30-day review if there is no objection.

I will send you the Word file once I have made all the changes if you are happy to produce the HTML and the PDF.
[LC] Gladly

John Colgrave

IBM

-----Original Message-----
From: Luc Clement [mailto:lclement@windows.microsoft.com]
Sent: 10 May 2003 22:58
To: John Colgrave; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Comments on the use of fragment identifiers in the "Using WSDL in a UDDI Registry, Version 2"

John,

Here's what I'd be content with: remove the use of "MUST" and replace it with "SHOULD" so that section 2.3.6 reads as follows:

"...the optional fragment identifier is used, then the value of the overviewURL SHOULD conform to the syntax described in Appendix C."

This would at least be consistent with 1.08 and not require the use of a WD that is no longer in development and arguably abandoned. As you suggest, when things settle down, we can incorporate the new developments (either those introduced in WSDL 1.1/1.2 or by the XML media registration which is expected) when we transition the TN to a BP. We could update 1.08 and 2.0 at the same time.

If you agree, please send me the latest version of the documents with this update and I'll have it posted to http://www.oasis-open.org/committees/uddi-spec/doc/draft/ and begin the 30-day review (it might get accepted before its birthday after all).

Luc

Luc Clément
Microsoft

Note: I'll gladly produce the HTML and PDF version for you; the version of Word that I'm using produces better quality HTML than earlier versions. Let me know if you would like to take up this offer.

From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Saturday, May 10, 2003 07:46
To: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Comments on the use of fragment identifiers in the "Using WSDL in a UDDI Registry, Version 2"

Luc,

Given that:

1. The use of fragment identifiers is optional, and not what we recommend as a best practice.

2. We updated the V1 BP to 1.08 just to add the same XPointer fragments, so if we change the V2 TN we will introduce a migration/compatibility problem. (Or are you proposing a 1.09 BP as well to change what we did for 1.08?)

3. As you say there are no simple alternatives.

4. The WSDL community is still discussing the issue for WSDL 1.2 and it is not yet clear if the approach chosen will be retro-fitted to WSDL 1.1.

5. I would like to publish the TN before its first birthday.

I propose that we leave the TN as it is. If things settle down in the near future we can incorporate the new developments when we transition the TN to a BP.

There is a later Working Draft than [5], from December 2002, so it does not seem to be entirely dormant, although the other pieces of XPointer have advanced to Recommendation.

John Colgrave

IBM

-----Original Message-----
From: Luc Clement [mailto:lclement@windows.microsoft.com]
Sent: 10 May 2003 06:50
To: John Colgrave
Cc: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Comments on the use of fragment identifiers in the "Using WSDL in a UDDI Registry, Version 2"

John,

I’ve received feedback that [5] referenced in the TN is a Working Draft that is now no longer in development because it was too big and complex to be widely implemented.

In section 2.3.6 the TN states that if “the optional fragment identifier is used, then the value of the overviewURL MUST conform to the syntax described in Appendix C.” The use of “MUST” is obviously problematic if we are going to continue to reference [5].

Unfortunately there are no simple alternatives and a perfect ready-made solution for us at this time within the context of the XPointer Framework [1] which represents the follow-on work to [5]. As it stands, the XPointer Framework does not address our immediate needs:

o The XPointer Framework [1] “#something” does not work for us given that WSDL doesn’t support ids

o The XPointer element() scheme [2] “#element(/1/2/6/5)” doesn’t make much sense to us given that it only works if a WSDL document that doesn’t change

We could consider the use of xPath and use an expression such as:

http://location/sample.wsdl#xmlns(wsdl=http://schemas.xmlsoap.org/wsdl/)xmlns(uddi=http://oasis-open.org/xpath)uddi:xpath(/wsdl:definitions/wsdl:portType[@name='StockQuotePortType"])

Doing so may prove to be more readability attainable given wide availability of xPath processors, but would require us to define this scheme. As an alternatives we could develop a scheme using the extension mechanism “#xmlns(uddi=http://oasis-open.org/fragments)uddi:portType(StockQuotePortType)”. For example: http://location/sample.wsdl#xmlns(uddi=http://oasis-open.org/fragments)uddi:portType(StockQuotePortType)

In short, there is no ready made solution. I’m told (i.e. I haven’t checked for myself) that the XML media type registration (which should be updated soon to point to the XPointer Framework), will allow people to use element(), xpointer() or any other fragment scheme that comes along. Constraining these extension points to improve interop can happen later on.

To summarize, at issue with section 2.3.6 of the TN are:

a. do we require a “MUST”? I propose no.
b. do we reference [5] given its state? I propose no.
c. do we use an xPath based scheme or the altenative extensions suggested above? I think we need to investigate what is being considered in the XML media type registration and/or what is currently being considered by wsdl 1.2 in terms of the "wsdl component designator" (which may or may not be really stable).

John, I recommend that c. be considered and investigated.

Luc

[1]     XPointer Framework, W3C Recommendation 25 March 2003, http://www.w3.org/TR/xptr-framework/
[2]     XPointer element() Scheme, W3C Recommendation 25 March 2003, http://www.w3.org/TR/xptr-element/
[3]     XPointer xmlns() Scheme, W3C Recommendation 25 March 2003, http://www.w3.org/TR/xptr-xmlns/

TN Reference:
[5] XPointer xpointer() Scheme, W3C Working Draft, 10 July 2002. http://www.w3.org/TR/2002/WD-xptr-xpointer-20020710/

uddi-spec message