W3C home > Mailing lists > Public > www-tag@w3.org > April 2003

Second Draft of summary of TAG issue abstractComponentRefs-37

From: David Orchard <dorchard@bea.com>
Date: Mon, 14 Apr 2003 11:33:29 -0700
To: <www-tag@w3.org>
Message-ID: <018d01c302b4$592e20f0$6401a8c0@beasys.com>

Starting with Jonathan Marsh's raising of the issue of expressing URIs for
abstract components, 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.
6. It should be possible to use relative URIs for the abstract components
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:airline.wsdl:ticketagent:listFlights:listFlightsRequest"

Pros:
- Compliant with URI specification & frag-identifiers
- Guaranteed to be long-lived

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

Notes:
This seems to re-open the urn vs url debate.  Maybe issue 37's high order
bit is url vs urn.
Not sure if this is the right syntax, the first version of the syntax had
"/" in it.

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
- Not sure if this is legal syntax, might need some extra juice to tie the
NCName to the "name" attribute.

4. Use 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
- 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.
- XPointer is not a recommendation.

Note:
XPointer element() Scheme [7], XPointer Framework [8], and xmlns() Schema
[9] are Recommendations.
Full Xpointer[10] is a WD that has no active work on it.

5. Use element(), XPointer framework

Sample URI is:
"http://airline.wsdl/ticketagent/#element(ticketagent/listFlights/listFlight
sRequest)"

Pros
- re-use element() syntax
- Compliant with URI specification & frag-identifiers

Cons
- Type is not apparent
- uris aren't guaranteed to be unique
- doesn't handle extensions

6. Develop WSD specific Xpointer scheme

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 ( I think...)

Cons:
- uris aren't guaranteed to be unique
- lengthy URIs
- need to develop WSD Scheme


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

Notes:
Noah provides some rationale for Schema's decisions on CDs at [13]

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

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

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.

9. 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/input(TicketAgent/listFlights/listFli
ghtsRequest)"


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.

10. Use a URI convention that slashes separate namespace URI and component
identifier.  Posted by Roy at [11]

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

Sample URI is
"http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest"

Option #2 URI is
"http://airline.wsdl/ticketagent/input(TicketAgent/listFlights/listFlightsRe
quest)"

Pros:
- Compliant with URI specification & frag-identifiers
- Relative URIs can be used
- Option #2 has type apparent

Cons:
- Can't tell where the namespace name ends and the name begins
- Type is not apparent
- Does not dependend upon RDDL, XPointer, etc.


11. Use URI query strings, where the ? separates the namespace URI and
component identifier.  Posted by Noah at [12]

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

Pros
- Compliant with URI specification & frag-identifiers
- Type is apparent

Cons
- No hierarchy of names
- No prevention of namespace conflicts (the joy of namespaces).  Not sure
how much of this is a problem for refering to WSD documents.
- Extensions not supported (need namespaces)

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.

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
[7] http://www.w3.org/TR/xptr-element/
[8] http://www.w3.org/TR/xptr-framework/
[9] http://www.w3.org/TR/xptr-xmlns/
[10] http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/
[11] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0148.html
[12] http://lists.w3.org/Archives/Member/w3c-ws-desc/2003Apr/0010.html (W3C
Member only)
[13] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0081.html
Received on Monday, 14 April 2003 14:33:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:17 GMT