Abstract Component References

&http-ident;-&iso6.doc.date;

Draft TAG Finding

&draft.day; &draft.monthname; &draft.year; &http-ident;-&draft.year;&draft.month;&draft.day; &http-ident; ( XML ) David Orchard BEA Systems, Inc. David.Orchard@BEA.com

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 . 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).

Chicago, Vancouver, Mountain View, et al.: World-Wide Web Consortium, Draft TAG Finding, 2003.

Created in electronic form.

English 2003-10-15: Published draft

TAG Recommendation

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. 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.

Related work

The TAG is working on a 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 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 which may prove useful to the WSD and other Working Groups.

WSDL Problem analysis

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 .

WSD Working Group Requirements

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 . 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.

Sample problem

A WSDL fragment of the form:

Sample WSDL Fragment <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> WSDL Solution space

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.

Namespace name and fragment identifier syntax

Option #1: query-string like format

Suggested at TAG Oct 2003 F2F . 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

ID attribute and XML fragment identifier syntax

Add an ID attribute and retain the name attribute

The WSD sample becomes:

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.

Unique Names

Require that name attributes be unique.

The WSDL fragment becomes

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

Full XPointer

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 , XPointer Framework , and xmlns() Schema are Recommendations.

Full Xpointer is a WD that has no active work on it.

XPointer framework and element()

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

WSD specific Xpointer scheme

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

XML Schema component designators description at . Some rationale for Schema's decisions on Component Designators at . 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

URN

Proposed and described in .

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.

RDDL fragment identifier syntax

First proposed in in . First raised in

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.

A URI convention that slashes separate namespace URI and component identifier

Suggested in Mar 24th telcon

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

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.

URI query strings

Option #1

Proposed in

Sample URI is

"http://airline.wsdl/ticketagent?portType=TicketAgent&operation=listFlights&input=listFlightsRequest"

Option #2

Proposed in . 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

References Issue Raising Ryman Explanation Use URNs Schema Component Designators RDDL Frag Id Nov 2002 TAG F2F Minutes Oct 2003 TAG F2F Minutes Xpointer element Xpointer framework Xpointer Namespaces Full XPointer Roy Fielding posting on fragments as names Use Query string Noah Mendelsohn posting on schema component designators TAG Issue Metadata in URI 31 Mar 24 TAG telcon Jonathan Marsh proposal on using query string TAG issue namespace name document 8 TAG issue URI good practice 40 Acknowledgements

The TAG would like to thank the following people for contributing to this finding: Jonathan Marsh, Noah Mendelsohn, Arthur Ryman.