Copyright © 2002-2003 W3C ® (MIT, ERCIM, 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 the issue raised by the WSD Working Group at [IssueRaise]. This finding contains the TAG response and a summary of the possible solution space to the problem. The WSD Working Group requirements, a sample use case, a short description of each solution, and the pros and cons of each solution is provided.
This document has been developed for discussion by the W3C Technical Architecture Group. This finding addresses issue abstractComponentRefs-37. 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 Related work
3 WSDL Problem analysis
3.1 WSD Working Group Requirements
3.2 Sample problem
4 WSDL Solution space
4.1 Namespace name and fragment identifier syntax
4.2 ID attribute and XML fragment identifier
syntax
4.3 Unique Names
4.4 Full XPointer
4.5 XPointer framework and element()
4.6 WSD specific Xpointer scheme
4.7 XML Schema Component designators
4.8 URN
4.9 RDDL fragment identifier syntax
4.10 A URI convention that slashes separate namespace URI
and component identifier
4.11 URI query strings
The TAG consensus is that description languages - such as WSDL, XML Schema, OWL - may use URIs that include fragment identifiers to identify abstract components described by that language. The TAG supports the use of fragment identifiers in the abstract component identifiers defined by the WSD working group. [Definition: An abstract component is a descriptive link to a resource]. In the WSDL language, the descriptive links are the constructs the WSDL language that describe Web services.
Description languages, such as WSDL and RDF, provide a language for describing things, known in the web context as resources. In the WSDL case, the resources are Web services. The name "Web service description language" is appropriately chosen for a language to describe resources that are web services. The description language defines the constraints on how to represent the description information. As defined in the web architecture, instances of a language are called components. Given that these components are information about a different resource, the different resources are called abstract components. A description of a resource must necessarily always refer to the resource being described and so the description component is always a link. Description languages typically provide mechanisms for identifying the abstract components, and these are called abstract component identifiers.
The identifier used to identify an abstract component should be useable to retrieve a representation of the corresponding abstract component description.
This implies descriptions should be deployed to be retrievable by simple dereference of the relevant identifier.
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.
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 namespace name format [issue8] . 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 into syntax design of the WSD fragment identifier syntax, believing that the WSD WG is better qualified for such activities. Members of the TAG did express support for Option 1 in the Namespace name and fragment identifier syntax section, but this is not a consensus opinion and the TAG plans no further elaboration on the WSD specific syntax. The TAG has taken up the issue of documenting URI construction best practices [issue40] which may prove useful to the WSD and other Working Groups.
The WSDL problem is how to refer to the abstract component specified in the WSDL language. Thus the WSDL problem is described as abstract component references. The WSD Working Group performed an analysis of requirements, possible solutions and proposed a solution, explained at [RymanExplanation].
This requirements section elaborates on the WSD WOrking Group's analysis of requirements. The elaboration is based upon further analysis of the solutions and numerous discussions.
It must be possible to identify each abstract component in a WSDL vocabulary with a URI.
It should be simple to create the WSDL abstract component constructs that are used for the URI.
It should be simple to create the URI
It should be possible to retrieve a namespace name document given an abstract component reference if the namespace name is used as part of the URI.
It should be possible to extract the symbol space information from the URI. The WSDL specification uses the symbol space name as the top-level specifier of the symbol space for the names defined by WSDL. There is an open TAG issue on the use of metadata in URI [Issuemetadatainuri-31] . The TAG does not offer an opinion on the relationship between symbol space names and metadata nor the suitability of this within URIs.
It should be extensible in order to identify components described by 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.
It should re-use existing naming or identifying constructs and fragment identifier syntax
The requirement for using relative URIs is not listed as a criteria here. It appears it is a "nice-to-have" but not a significant factor in any recommendation or decision.
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>This section describes the various abstract component identifier syntax solutions and fragment syntax changes for WSDL abstract component references that have been collected during the course of this finding.
Each solution met a varying amount of the requirements. No one solution met all requirements.
Option #1: query-string like format
Suggested at TAG Oct 2003 F2F [2003110tagf2f] . Query string format based upon query string with single argument 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 to author WSD constructs.
simple to author URIs
symbol space is apparent
Option #1 does not use parenthesis.
Cons:
Unsure how extensions are identified.
Requires inventing WSDL specific fragment identifier syntax
Add an ID attribute and retain 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
extensions are identifiable
Cons:
hard for authors of WSD documents.
hard to manage the space of Ids to guarantee URI identifies single component across compound WSDL documents
Overlap between names and ids.
Symbol space 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:
Reinvents some of ID constraints.
hard for authors of WSDL documents.
Symbol space 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
Symbol space is apparent
extensions are identifiable
easy to author WSDL documents
Cons:
complex syntax
requires XPointer processor
URI may identify multiple components.
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
URI may identify multiple components.
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:
Symbol space is apparent
handles extensions
Cons:
URI may identify multiple components.
URIs are complex to create
need to develop WSD specific fragment identifier syntax.
Uses balanced parens
XML Schema component designators description at [scuds] . Some rationale for Schema's decisions on Component Designators at [noahonscuds] . The sample URI is
"http://airline.wsdl/ticketagent/#xmlns(ta=http://www.airline.wsdl/ticketagent/)wsdl(/portType(ta:TicketAgent)/operation(listFlights)/input(listFlightsRequest))"
Pros:
Symbol space is apparent
extensions are identifiable
Cons:
complex syntax
Schema component designators still under development
Uses balanced parens
Proposed and described in [useURN] .
The URI sample would be
"urn:wsdl:airline.wsdl:ticketagent:listFlights:listFlightsRequest"
Pros:
Cons:
embeds URIs into URNs
URI not dereferenceable
Unsure how extensions are identified
No advantage over http: URIs with respect to longevity as a new URN needs to be minted any time the interface changes.
First proposed in in [rddl-fragid] . First raised in [200111tagf2f]
Sample URI is
"http://airline.wsdl/ticketagent/#wsdl/input.TicketAgent.listFlights.listFlightsRequest"
Pros:
Symbol space 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 fragment 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 in Mar 24th telcon [mar24telcon]
Quoting the suggestion: "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.". A disagreement 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:
Option #2,3,4,5 has symbol space apparent
Does not require a WSD syntax
Cons:
Can't tell where the namespace name ends and the name begins Roy:So?
Symbol space is not apparent in option #1.
#5 has balanced parens.
Option #1
Proposed in [usequery]
Sample URI is
"http://airline.wsdl/ticketagent?portType=TicketAgent&operation=listFlights&input=listFlightsRequest"
Option #2
Proposed in [jonathanonusingquery] . This suggests a single name with a value that uses periods as separators.
http://airline.wsdl/ticketagent/?wsdl-input=TicketAgent.reserveFlight.reserveFlightRequest
Pros:
Symbol space is apparent
Cons:
Overrides a portion of the URI space
Option #1: No hierarchy of names
No prevention of namespace conflicts. Not sure how much of this is a problem for referring to WSD documents.
Extensions not supported.
need to develop WSD specific query parameters.
A dereference operation will require that a WSDL document not be returned, rather the abstract component. Otherwise the client cannot interpret the document properly.
Notes:
I wonder if there would be a way of getting QNames into this for extensions.
Roy: this solution defeats the purpose of assigning names