First Draft of summary of TAG issue abstractComponentRefs-37

Starting with Jonathan Marsh's raising of the issue of expressing URIs for
abstract componenents, at [1], this note attempts to summarize 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.  Please suggest any text that should be
added, changed or deleted in this summary of solution space.

Requirements

1. It must be possible to identify each conceptual element in a WSDL
vocabulary with a URI.
2. It should be simple to create and use the URI
3. It should be possible to extract the type information from the URI
4. It must be compliant with the URI specification.
5. 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.

Use case

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?

Solutions:

1. Use URNs with a new urn fragment identifier syntax.  This was the first
proposal by Arthur [3].  The URI sample would look like
"urn:wsdl:http://airline.wsdl/ticketagent/listFlights/listFlightsRequest"

Pros:
- Compliant with URI specification & frag-identifiers

Cons:
- embeds URIs into URNs
- URI not dereferenceable
- Unsure how extensions are identified

2. Require each WSDL element have a unique ID attribute and use XML fragment
identifier syntax.  The WSD sample would become:

<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
- Compliant with URI specification & frag-identifiers
- extensions are identifiable

Cons:
- hard for authors of WSD documents.  Note: if the generic use case for WSD
is for tooling, is this really an issue?
- hard to manage the space of Ids to guarantee uniqueness across compound
WSDL documents
- Overlap between names and ids.
- Type is not apparent.

3. Require Unique NCNames.

<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/#TicketAgentPortTypelistFlightsOperationlis
tFlightsRequestInput"

Pros:
- Compliant with URI specification & frag-identifiers
- extensions are identifiable

Cons:
- higher complexity names
- Type is not apparent

4. Use full XPointer.  The sample URI is
http://airline.wsdl/ticketagent/#xmlns((w=http://schemas.xmlsoap.org/wsdl/)x
pointer(//w:portType[@name="TicketAgent"]/w:operation[@name="listFlights"]/w
:input[@name="listFlightsRequest"])

Pros:
- re-use XPointer syntax, which is a rec
- Compliant with URI specification & frag-identifiers
- Type is apparent
- extensions are identifiable

Cons:
- complex syntax
- requires XPointer processor
- uris aren't guaranteed to be unique.

5. Use XML Schema Component designators [4].  The sample URI is
"http://airline.wsdl/ticketagent/#xmlns(ta=http://www.airline.wsdl/ticketage
nt/)
wsdl(/portType(ta:TicketAgent)/operation(listFlights)/input(listFlightsReque
st))"

Pros:
- Compliant with URI specification & frag-identifiers
- Type is apparent
- extensions are identifiable

Cons:
- complex syntax
- still under development


6. Use namespace name and new fragment identifier syntax.  This is the
current WSD proposal.

The sample URI is
"http://airline.wsdl/ticketagent/#operation(TicketAgent/listFlights)".

Pros:
- simple for authors of WSD documents.
- requires no changes to WSD syntax
- Type is apparent

Cons:
- violation of URI fragment identifier rules that fragment identifiers are
based upon the media type of the dereferenced content.
- Unsure how extensions are identified.

7. Use a to be devoloped RDDL fragment identifier.  Tim Bray's first posting
on this is [5], and the use of RDDL fragment identifiers that are specific
to RDDL references was raised in [6]

Sample URI is
"http://airline.wsdl/ticketagent/#wsdl/operation(TicketAgent/listFlights)"


Pros:
- Compliant with URI specification & frag-identifiers
- 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.

Cheers,
Dave

[1] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0207.html
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0021.html
[3]
http://lists.w3.org/Archives/Public/www-ws-desc/2002Oct/att-0084/01-URI-Refe
rences.html
[4] http://www.w3.org/TR/xmlschema-ref/
[5] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0064.html
[6] http://www.w3.org/2002/11/18-tag-summary

Received on Thursday, 10 April 2003 00:59:16 UTC