Third Draft of summary of TAG issue abstractComponentRefs-37

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 must be compliant with the URI specification.
4. 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.
<roy>Why?  Those sound like actions and metadata to me, which don't belong
in the URI.</roy>
5. It should be possible to use relative URIs for the abstract components

Requirements under debate
6. 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.
<roy>
That's simple: metadata should never be in the URI.  That has been a
principle of URI design all the way back to discussion in 1993.
Basically, if something can be identified without the use of the
metadata, then the presence of the metadata causes an infinite
number of URIs to identify the same thing.  That's mega-bad.</roy>

7. It should be possible to retrieve a namespace name document given an
astract component reference.

Sample problem

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

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.

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:
- seems like it would be better to rename "name" to ID, why re-invent ID
constraints.  Any length restrictions?
- 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 #1 is:
"http://airline.wsdl/ticketagent/#element(ticketagent/listFlights/listFlight
sRequest)"

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

The "." separator may be better suited than / within parens, due to parser
implementation issues.

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
- <roy>use of parens is goofy</roy>

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.
- <roy>we don't need another universal media type</roy>

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

Roy has also commented that balanced parens in URIs are a bad thing, as they
confuse the hierarchical naming of the resource.

Sample URI is
"http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest"
<roy>preferred approach</roy>
Option #2 URI is
"http://airline.wsdl/ticketagent/input/TicketAgent/listFlights/listFlightsRe
quest"

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</roy>

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

Pros:
- Compliant with URI specification & frag-identifiers
- 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?
</roy>
- Type is not apparent
- #5 has balanced parens.


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

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
[14]  http://www.w3.org/2001/tag/ilist#metadataInURI-31

Received on Thursday, 19 June 2003 18:03:22 UTC