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

RE: Second Draft of summary of TAG issue abstractComponentRefs-37

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Fri, 25 Apr 2003 13:52:21 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04A074CC@0-mail-1.hpl.hp.com>
To: "'David Orchard'" <dorchard@bea.com>
Cc: www-tag@w3.org

Hi David,

I have an outstanding TAG action [1] to draft a finding to resolve
metadataInURI-31 [2]. I'm conscious this has been languishing for a while
and I need to make some progress - but I believe that I'm likely lift the
lid of the URI opacity tin. Anyway, when we accepted issue-31 [3] it was
with the express intent that saying that the encoding of metadata in URI was
exactly the wrong thing to be doing. I'm trying now to reconcile that intent
with the third requirement below:

> 3. It should be possible to extract the type information from the URI

These two seem at odds. Any thoughts?

Thanks,

Stuart
--
[1] http://www.w3.org/2003/02/06-tag-summary.html#metadataInURI-31
[2] http://www.w3.org/2001/tag/ilist#metadataInURI-31

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: 14 April 2003 19:33
> To: www-tag@w3.org
> Subject: Second 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 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/#TicketAgentPortTypelistFligh
> tsOperationlis
> 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.xmlso
> ap.org/wsdl/)x
> pointer(//w:portType[@name="TicketAgent"]/w:operation[@name="l
> istFlights"]/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/listFlig
> hts/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.xmlso
> ap.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(li
> stFlightsReque
> 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/listFlight
> s/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/listF
> lights/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/listF
lightsRequest"

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 Friday, 25 April 2003 08:52:53 GMT

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