R120: URI References
W3C WS Description WG F2F
Boston, 2002-11-11
Arthur Ryman
ryman@ca.ibm.com
Requirement
R120: The description language MUST
ensure that all conceptual elements in the description of Messages
are addressable by a URI reference [IETF RFC 2396]. (From the
Semantic Web. Last discussed 11 June 2002.)
- URI reference = URI + fragment
identifier
- Semantics of fragment identifier depends
on data retrieved via the URI
- Format and interpretation of the
fragment identifier depends on the media type
- TAG finding states that a media type
should be defined for WSDL
application/wsdl+xml
, text/wsdl+xml
[IEFT RFC 3023]
RFC 2392:URI References
A URI reference may be absolute or
relative, and may have additional information attached in the form
of a fragment identifier.
URI-reference = [ absoluteURI |
relativeURI ] [ "#" fragment ]
When a URI reference is used to perform
a retrieval action on the identified resource, the optional
fragment identifier, separated from the URI by a crosshatch ("#")
character, consists of additional reference information to be
interpreted by the user agent after the retrieval action has been
successfully completed.
The semantics of a fragment identifier
is a property of the data resulting from a retrieval action,
regardless of the type of URI used in the reference. Therefore, the
format and interpretation of fragment identifiers is dependent on
the media type [RFC2046] of the retrieval result.
TAG Finding
- TAG Finding: Internet Media Type
registration, consistency of use
W3C Working Groups engaged in defining
a language SHOULD arrange for the registration of an Internet Media
Type (defined in RFC 2046 [RFC2046]) for that language; see
[IANAREG] for registration instructions.
RFC 3023: XML Media Types
To enable the exchange of XML network
entities, this document standardizes five new media types --
text/xml, application/xml, text/xml-external-parsed-entity,
application/xml-external-parsed-entity, and application/xml-dtd --
as well as a naming convention for identifying XML-based MIME media
types.
To facilitate the processing of such
types, media types based on XML, but that are not identified using
text/xml or application/xml, SHOULD be named using a suffix of
'+xml' as described in Section 7.
- WSDL is no more or less humanly readable
than XML Schema and has similar usage
- Define both
application/wsdl+xml
and
text/wsdl+xml
?
URI Alternatives
- What URI can be used with a URI
reference?
- The URI of a WSDL document
- Consistent with the normal use of
fragment identifiers in HTML and XML (XPointer)
- Not a good choice as an identifier of a
concept that is independent of any particular document that
contains its definition
- It should be easy to compare identifiers
(e.g. without retrieving documents)
-
The URI of a WSDL namespace
- Is a suitable abstraction for concepts
that exist outside of particular instance documents
- May not be retrievable, or if retrieval
may point to a document that describes the namespace instead of
WSDL
- Therefore can't use fragment identifiers
with this
- c.f. XS-NUN has yet to define a URI for
the schema-as-a-whole
urn:wsdl: Scheme for Description-as-a-Whole
- Introduce a new urn scheme to describe the set of all
conceptual elements in a WSDL namespace, c.f. XS-NUN
schema-as-a-whole
- The resource described by a urn:wsdl:namespace URI in a given
context is the set of all conceptual elements defined by the WSDL
documents associated with the namespace URI, e.g. via
<import>
elements.
- e.g.
urn:wsdl:http://airline.wsdl/ticketagent/
is the
description-as-a-whole for the http://airline.wsdl/ticketagent/
namespace
- This was dropped from the initial
proposal
- Therefore only the use of URIs of WSDL
documents makes sense with fragment identifiers
Fragment Alternatives
- ID
- QName
- XPointer
- XML Schema: Normalized Universal
Names
- XPointer Framework
ID
- Add a required ID attribute to each
conceptual element, e.g.
<portType id="TravelAgentPortType"
name=…>
- Pros:
- Simple
- Fits with bare XPointer syntax, e.g.
#TravelAgentPortType
- Cons:
-
The type of conceptual element is not
apparent
- Makes authoring more difficult
- What about multiple documents within a
namespace?
QNames
- Make QNames unique and construct
fragments from them, e.g.
#extended-name(http://airline.wsdl/ticketagent/,
listFlightsRequest)
- Pros:
- Simple
- WSDL already uses QNames
- Cons:
- The type of the conceptual element is
not apparent
- Creating unique QNames makes authoring
more difficult
- What about multiple documents within a
namespace?
XPointer
- Use full XPointer to identify
elements
- Pros:
- XPointer is an existing standard
- Conceptual element type is apparent
- Cons:
- XPointer syntax is very verbose, e.g.
#xmlns(w=http://schemas.xmlsoap.org/wsdl/)
xpointer(//w:portType[@name="TicketAgent"]/w:operation[@name="listFlights"]/w:input[@name="listFlightsRequest"])
- XPointer processor required
- XPointer expressions are not unique
XML Schema: NUN
- Clone XML Schema: Normalized Universal
Names, e.g.
#xmlns(ta=http://www.airline.wsdl/ticketagent/)
ws-nun(/portType(ta:TicketAgent)/operation(ta:listFlights)/input(ta:listFlightsRequest))
- Pros:
- XML Schema: NUN is a proposed
standard
- Consistent with XML Schema
- Conceptual element type is apparent
- Cons:
- Verbose and complex due to greater XML
Schema complexity
- WSDL NUN processor required
XPointer Framework
- Use XPointer Framework to define WSDL
fragments as proposed in R120: WSDL URI References
- Fragment syntax is
element-name(localname-path)
- e.g.
#input(TicketAgent/listFlights/listFlightsRequest)
- Pros:
- XPointer Framework is a standard
- Simple
- Fragments are highly readable and
concise
- Cons:
- Inconsistent with XML Schema
- Doesn't handle WSDL Extension elements
(yet)
Conclusion
- We should define
application/wsdl+xml
and text/wsdl+xml
- Do we need to be able to identify
elements of a namespace as opposed to elements of a document?
- Do extension elements define conceptual
elements? If so, we need to have URI references for them too.
- Let's pick a fragment syntax (I
recommend simple XPointer Framework approach).