Comments on the use of fragment identifiers in the "Using WSDL in a UDDI Registry, Version 2"

["Luc Clement" <lclement@windows.microsoft.com>]

Title: 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:

• The XPointer Framework [1] “#something” does not work for us given that WSDL doesn’t support ids
• 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/