Luc,
Given
that:
- The use of fragment
identifiers is optional, and not what we recommend as a best
practice.
- 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?)
- As you say there
are no simple alternatives.
- 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.
- 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.
-----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,
Ive 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 doesnt support
ids
o
The XPointer element()
scheme [2] #element(/1/2/6/5) doesnt make much sense to us given that it
only works if a WSDL document that doesnt 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. Im told (i.e. I havent 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/