Copyright © 2003 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This finding describes the TAG's response to the question of the suitability of using URIs with fragment identifiers for identifying abstract components, as exemplified by Jonathan Marsh's raising of the issue for the WSD working group at [IssueRaise]. This finding contains the TAG response and a summary of the possible solution space to the problem. Requirements, a sample use case, a short description of each solution, and the pros and cons of each solution is provided. Arthur Ryman's posting of the current WSDL solution [2] provides excellent background material.
This document has been developed for discussion by the W3C Technical Architecture Group. It does represent a draft of the consensus opinion of the TAG.
Publication of this finding does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time.
Additional TAG findings, both approved and in draft state, may also be available. The TAG expects to incorporate this and other findings into a Web Architecture Document that will be published according to the process of the W3C Recommendation Track.
Please send comments on this finding to the publicly archived TAG mailing list www-tag@w3.org (archive).
1 TAG Recommendation
2 Problem analysis
2.1 Requirements
2.2 Sample problem
3 Solution space
3.1 Namespace name and new fragment identifier syntax.
3.2 Use ID attribute and XML fragment identifier syntax
3.3 Unique Names
3.4 Full XPointer
3.5 XPointer framework and element()
3.6 WSD specific Xpointer scheme
3.7 XML Schema Component designators
3.8 URN
3.9 RDDL fragment identifier syntax
3.10 A URI convention that slashes separate namespace URI and component identifier
3.11 URI query strings
The TAG consensus is that description languages - such as WSDL, XML Schema, OWL - should define fragment identifiers for identifying a language's abstract components. The TAG supports the use of fragment identifiers by the WSD working group.
Good Practice
Description languages that identify abstract components should define a fragment identifier syntax for these components.
The TAG does believe that the issue of identifying abstract components and the use of namespace names has architectural implications for the Web. The TAG has consensus that a vocabulary can recommend that an instance of the vocabulary is available upon de-referencing the namespace name.
Good Practice
Description languages that identify abstract components should make available an instance of the language at the URI used for identifying the abstract component.
A typical base URI is the namespace name for the instance of the language.
The TAG is working on a human-centric namespace name format. This format and the related fragment identifier syntax are not sufficiently advanced in the W3C process for the TAG to recommend that a working group use them. The abstract component identifiers as defined in a particular language, and the relationship to the description language syntax, the fragment identifier syntax, the use of a namespace name document, and the namespace name document fragment identifier syntax is not clear at this time. The TAG expects to continue work on this area.
As for the particulars of the syntax, the TAG does not wish to delve deeply into syntax design of the WSD fragment identifier syntax, believing that the WSD WG is better qualified for such activities. A number of TAG members did have some particular comments on URI syntax construction. The use of parenthesis should be avoided, and the use of periods "." as a separator seems useful. Effectively, the TAG offers a syntax that is very close to the last syntax produced by the Jonathan Marsh but using fragment identifier separators. To be clear, it is some TAG members that offer this opinion on the specific syntax rather than TAG consensus. The option that some TAG members support is option #1A.
The TAG is planning on being available for liaison meetings in the Tech plenary 2004 week. Further discussion of this issue, and others, with the WSD WG is possible should the WSD WG desire.
It must be possible to identify each abstract component in a WSDL vocabulary with a URI.
It should be simple to create and use the URI.
It should be possible to retrieve a namespace name document given an astract component reference if the namespace name is used as part of the URI.
It should be possible to use relative URIs for the abstract components
It should be possible to extract the type information from the URI. There has been some discussion that embedding metadata, particularly the type of the refered to thing, is a bad idea. There is an open TAG issue on this, metadata in URI[14]. It might be useful to provide guidance, either specific to this issue or in issue 14, as to when metadata such as types either should or should not be put into URIs.
It should be able to identify WSDL extensions, ala soap:binding, soap:operation, soap:address, soap:body, soap:action, soap:fault, soap:header, soap:headerfault, http:address, http:binding, http:urlEncoded, http:urlReplacement, mime:content, etc.
A WSDL fragment of the form:
<definitions name="TicketAgent" targetNamespace="http://airline.wsdl/ticketagent/">
<portType name="TicketAgent">
<operation name="listFlights" parameterOrder="depart origin destination">
<input name="listFlightsRequest" message="tns:listFlightsRequest" />
......
</definitions>
What is the syntax of the identifier for this input operation?
Option #1: query-string like format
Suggested by Norm Walsh at Oct 2003 F2F. Query string format based upon Jonathan marsh proposal, listed later in this document.
Sample URI is
http://airline.wsdl/ticketagent/#input=TicketAgent.reserveFlight.reserveFlightRequest
Option #2: symbol space name followed by parenthesis containing component identifier within symbol space.
Original WSDL Proposal.
The sample URI is
"http://airline.wsdl/ticketagent/#input(TicketAgent/listFlights/listFlightsRequest)".
Pros:
simple for authors of WSD documents.
requires no changes to WSD syntax
Type is apparent
Option #1 does not use parenthesis.
Cons:
Unsure how extensions are identified.
Add an ID attribute and retaining the name attribute
The WSD sample becomes:
<definitions id="TA" name="TicketAgent" targetNamespace="http://airline.wsdl/ticketagent/">
<portType id="TAPType"name="TicketAgent">
<operation id="TAPTypeLOF" name="listFlights" parameterOrder="depart origin destination">
<input id="TAPTypeLOFReq" message="tns:listFlightsRequest" name="listFlightsRequest"/>
......
</definitions>
The URI sample is "http://airline.wsdl/ticketagent/#TAPTyleLOFReq"
Pros:
re-use at least the ID portion of XML fragment identifier syntax
Simple to implement WSDL parsers
extensions are identifiable
Cons:
hard for authors of WSD documents.
hard to manage the space of Ids to guarantee uniqueness across compound WSDL documents
Overlap between names and ids.
Type is not apparent.
Require that name attributes be unique.
The WSDL fragment becomes
<definitions name="TicketAgent" targetNamespace="http://airline.wsdl/ticketagent/">
<portType name="TicketAgentPortType" >
<operation name="TicketAgentPortTypelistFlightsOperation" parameterOrder="depart origin destination">
<input name="TicketAgentPortTypelistFlightsOperationlistFlightsRequestInput" message="tns:listFlightsRequest" />
......
</definitions>
The URI sample is
"http://airline.wsdl/ticketagent/#TicketAgentPortTypelistFlightsOperationlistFlightsRequestInput"
Pros:
extensions are identifiable
Cons:
Seems to reinvent much of ID constraints.
higher complexity names
Type is not apparent
The sample URI is
http://airline.wsdl/ticketagent/#xmlns((w=http://schemas.xmlsoap.org/wsdl/)xpointer(//w:portType[@name="TicketAgent"]/w:operation[@name="listFlights"]/w:input[@name="listFlightsRequest"])
Pros:
re-use XPointer syntax
Type is apparent
extensions are identifiable
Cons:
complex syntax
requires XPointer processor
uris aren't guaranteed to be unique.
XPointer is not a recommendation.
Note:
XPointer element() Scheme [xptr-element], XPointer Framework [xptr-framework], and xmlns() Schema [xptr-ns] are Recommendations.
Full Xpointer [xpointer-full] is a WD that has no active work on it.
Sample URI #1 is:
"http://airline.wsdl/ticketagent/#element(ticketagent/listFlights/listFlightsRequest)"
Sample URI #2 is:
"http://airline.wsdl/ticketagent/#element(ticketagent.listFlights.listFlightsRequest)"
The "." separator may be better suited than / within parens, due to parser implementation issues.
Pros
re-use element() syntax
Cons
Type is not apparent
uris aren't guaranteed to be unique
doesn't handle extensions
roy:use of parens is goofy
Sample URI is
"http://airline.wsdl/ticketagent/#xmlns(w=http://schemas.xmlsoap.org/wsdl)w:input(ticketagent/listFlights/listFlightsRequest)"
Pros:
type is apparent
handles extensions
Cons:
uris aren't guaranteed to be unique
lengthy URIs
need to develop WSD Scheme
Concerns about usability of Xpointer with balanced parens
XML Schema component designators description at [scuds]. The sample URI is
"http://airline.wsdl/ticketagent/#xmlns(ta=http://www.airline.wsdl/ticketagent/)wsdl(/portType(ta:TicketAgent)/operation(listFlights)/input(listFlightsRequest))"
Pros:
Type is apparent
extensions are identifiable
Cons:
complex syntax
Schema component designators still under development
Uses balanced parens
Notes:
Noah provides some rationale for Schema's decisions on Component Designators at [noahonscuds]
First proposal by Arthur Ryman[useURN].
The URI sample would be
"urn:wsdl:airline.wsdl:ticketagent:listFlights:listFlightsRequest"
Pros:
Independence from potential dereferencing operations
Cons:
embeds URIs into URNs
URI not dereferenceable
Unsure how extensions are identified
No advantage over http: URIs wrt longevity as a new URN needs to be minted any time the interface changes.
Tim Bray's first posting on this is [rddl-fragid]. Dave Orchard first raised this in [tagf2f]
Sample URI is
"http://airline.wsdl/ticketagent/#wsdl/input.TicketAgent.listFlights.listFlightsRequest"
Pros:
Type is apparent
incorporates RDDL into Web services
Could unify schema, wsdl, other description languages with namespaces.
Cons:
Idea is a barely beyond a twinkle in our eyes. It requires specification of RDDL frag identifier syntax, and typical time to develop issues.
Unknown whether it will actually solve the problem.
Unsure how extensions are identified.
roy:we don't need another universal media type.
Suggested by Roy at [mar24telcon]
He says "In the CMS world, a compound hierarchical document is no different from a hierarchical directory system -- all names are hierarchies and the names are separated by "/" all the way down to the smallest atom of content. WSDL defines a compound document namespace rooted at its namespace URI. So, add a slash and define the hierarchy below the namespace URI according to WSDL.". Roy disagrees with using frag-ids in names in [royonfragsasnames]
Sample URI is
"http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest"
roy:preferred approach
Option #2 URI is
"http://airline.wsdl/ticketagent/input/TicketAgent/listFlights/listFlightsRequest"
Option #3 URI is
"http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest/input"
Option #4 URI is
"http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest;input"
Roy:preferred approach if input is required
Option #5 URI is
"http://airline.wsdl/ticketagent/input(TicketAgent/listFlights/listFlightsRequest)"
Pros:
Relative URIs can be used (except with option #5)
Option #2,3,4,5 has type apparent
Does not dependend upon RDDL, XPointer, etc.
Cons:
Can't tell where the namespace name ends and the name begins Roy:So?
Type is not apparent
#5 has balanced parens.
Option #1
Posted by Noah at [usequery]
Sample URI is
"http://airline.wsdl/ticketagent?portType=TicketAgent&operation=listFlights&input=listFlightsRequest"
Option #2
Posted by Jonathan Marsh at [jonathanonusingquery]. Suggest a single name with a value that uses periods as separators.
http://airline.wsdl/ticketagent/?wsdl-input=TicketAgent.reserveFlight.reserveFlightRequest
Pros
Compliant with URI specification
Type is apparent
Cons
Overrides a portion of the URI space
No hierarchy of names
No prevention of namespace conflicts. Not sure how much of this is a problem for refering to WSD documents.
Extensions not supported (need namespaces). Perhaps extensions can be supported, but we have to say that no name clashes are allowed?
Notes:
I wonder if there would be a way of getting QNames into this for extensions.
This does seem close to re-inventing XPointer though.
Roy: this solution defeats the purpose of assigning names