RE: abstractComponentRefs-37 & RDDL

Hi Tim,

Firstly thanks for taking the first crack at this... I have a few comments
weaved in below.

Summary

1) Absent a mechanism for mapping between qualified names ie.{URIRef,
localName) tuples and URI refs, one has to make a choice, I think, between
using qualified names or URI to identify things (like the abstract
components of a WSDL interface).

2) Even with such a mechanism, qualified names alone in WSDL which uses
context within the document to disambiguate between the same qname being
used to identify ports, portTypes, operations, message and part message
(schema)... If one want unambiguous URI for naming the abstract components
of a WSDL interface the context of use has to be accounted for in the
mapping.

3) I don't think trading fragment ID syntax associated with WSDL for
fragment ID syntax associated with RDDL really addresses the problem.

Best regards

Stuart
--
> -----Original Message-----
> From: Tim Bray [mailto:tbray@textuality.com] 
> Sent: Monday, March 31, 2003 7:45 AM
> To: WWW-Tag
> Subject: abstractComponentRefs-37 & RDDL
> 
> 
> 
> At our last telecon, the TAG accepted this new issue, with some concern 
> because there is overlap with existing issues (rdfmsQnameUriMapping-6, 
> namespaceDocument-8 at least).
> 
> I took an action item to post a few words on this.
> 
> I think the best place to start getting a feel for it is with Paul 
> Cotton's note at
> 
>    http://lists.w3.org/Archives/Public/www-tag/2003Feb/0207.html
> 
> which encloses another note from Jonathan Marsh.  I encourage people to 
> read Jonathan's statement of the problem.
> 
> Basically, they want to point to a structure inside an WSDL instance, 
> and they want to use an XPointer-type thing to do.

Hmmm... That was not my reading. What I think they are trying to do is give
URI (Ref) based names to things (WSDL Components) like ports, portTypes,
message and message part (schema), operations (scoped by portType), bindings
and services....

The descriptions of these components are within a WSDL instance, but
components themselves are abstract and not within the WSDL instance.

> The only real handle 
> shared between sender and receiver they have to start with is the 
> namespace defined for the WSDL, i.e they might not have a pointer to the 
> WSDL itself, for good reasons such as having local behind-the-firewall 
> copies and so on.  So they're proposing just doing something 
> along the lines of
> 
>                  http://namespace..#xpointer
> 
> As Jonathan points out, this is bogus, the semantic of a fragment 
> identifier depends on the media-type of the representation you get back 
> when you dereference the URI.  Since that could conceivably be an HTML 
> document, an RDF document, an XML Schema, or who knows what, the use of 
> the #fragment notation here seems just basically broken.
>
> However, I personally think the following are all reasonable 
> things to want to do:
> 
> 1. Use a namespace name as a basis for shared identification
> 2. Have a hierarchical naming setup inside something like a
>     WSDL instance
> 3. Tie #1 and #2 together into a URI, because URIs are useful

I think that you have hit the nail on the head here. I think that we have to
be clear about what it is we want to 'the' identifiers on the Web. By and
large the primary kind of identifier on the Web is the URI. The things in a
namespace are identified by a URI which names the namespace and a localname
within that namespace - point being that these are *not* URI and in general
there is not a mapping between {URIRef, localname} and {URIRef} - this is
the substance of rdfmsQnameURIMapping-6.

Given that I'll try a rewrite of your 3 bullets:

1. Use a namespace as the basis to organise the names of related abstract
WSDL components.
2. Use a hierarchical naming scheme to reflects the relationship between
components.
3. Use URI(References) to name abstract WSDL components.

Still not happy... 1. and 3. seem to be at odds. Without a mapping between
{NamespaceName, localName} and URI references I think you have to make a
choice as to whether you're going to use URI or namespaces as the basis of
identification (granted URI are the basis of identifying a namespace). In
addition, WSDL also uses localNames in a context dependent way. So the
qnames of the form tns:localName in a WSDL document are not enough to
disambiuate what component is being described - a port, portType and message
can all share the same localName.

> 
> So... if we don't want to accomplish #3 by abusing the #fragment 
> identifier, what can we do?
> 
> The best idea I've heard involves RDDL.  This isn't my idea, I forget 
> where I heard it first but suspect it might have been from Dave Orchard. 
>   Let's suppose that you have a RDDL that identifies 2 related 
> resources, and let's suppose that you require that pointers to related 
> resources have an ID so you can address them.
> 
>   http://example.com/ns/foo.rddl ==> RDDL for this namespace
>   foo.rddl#jar: Related (JavaClass) ==>http://example.com/jars/foo.jar
>   foo.rddl#wsdl: Related (WSDL) ==> http://example.com/WSDLs/foo.wsdl
>
> OK, now suppose I want to identify (using Jonathan's example) 
> "operation(TicketAgent/listFlights)" inside the WSDL. I'm wondering if 
> you could bridge through the RDDL to get there with something along the 
> lines of
> 
> http://example.com/ns/foo.rddl#wsdl/operation(TicketAgent/listFlights)

Hmmm... I think we're back at the original question of what it is you're
trying to name... Some region of text in a wsdl document or the abstract
thing that that piece of wsdl document describes.

Here we've gone from:

	http://example.com/ns#operation(TicketAgent/listFlights)

to
	
http://example.com/ns/foo.rddl#wsdl/operation(TicketAgent/listFlights)

I think I still prefer as we discussed in the call:

	http://example.com/ns/operation/TicketAgent/listFlights

It is a URI; it avoids fragment identifiers; it could be dereferenced to
provide some description of the listFlights operation in the portType Ticket
agent. Equally, like http://purl.org/dc/elements/1.1/title it could also be
organised to redirect to a larger work that describes a number of related
concepts, http://dublincore.org/2003/03/24/dces#title - nevertheless, the
former is the identifier for the Dublin Core concept of title. 

http://example.com/ns/operation/TicketAgent/listFlights could be arranged to
redirect into a copy of the relevant WSDL file, but this URI would name the
operation, while the redirection would yield a different URI ref, an a
fragment ID that indexes the corresponding part of the representation.

> So the stuff after the "#wsdl/" is treated as a fragment identifier in 
> the related-resource which the link identified by #wsdl points at.  This 
> could all be done perfectly legally by registering a media-type for RDDL 
> and saying this is how fragments behave.

But... that's really no different from registering a media-type for WSDL and
specifying how fragment ids index into a WSDL document... and one is still
faced question of whether dereferencing the WSDL target namespace name would
yield WSDL, RDDL, XML-Schema, DAML, some other representation of the
namespace or 404.

> And in fact, it is fairly true 
> to the basic semantic of #fragments, namely you have to fetch the RDDL 
> to find out what the #wsdl points at so you can figure out what to do 
> with the rest of the fragment.  On the other hand, that '#' jammed in 
> the middle of of the URI is perhaps troubling.

I would have thought that the natural RDDL way to deal with a WSDL namespace
would be to produce a RDDL file that referenced the the WSDL resource with a
relevant nature and purpose along with some human readable description of
the interface that the WSDL describes.

Going on to try to weave the names of things described by the referenced
resource into some RDDL fragment identifiers seems to me to go too far. What
would you do for DTD's... Would you try to name entity definitions and
element content models within the RDDL fragment id syntax?

	#dtd/entity(anEntity)

And what about XML-Schema components and stylesheets and...
	#xmls/????
	#css/????

Maybe I've mis-understood your intent, but the point of Jonathan's question
was "How should WSDL use URI/URI ref like things to name abstract components
in a WSDL interface?. I don't think that the answer (should) involve
absorbing WSDL's conceptual model of a WS interface into the fragment
identifiers syntax for RDDL. It would seem at least reasonable to consider
weaving WSDL conceptual model into the frag ID systax for a WDSL media-type
- which is Jonathan's starting point, but then he note what I'll call a
split-horizon problem, in that a WSDL description describes thing in a
targetNameSpace, but the namespace and the WSDL document are (rightly)
different resources - and so that fragId scheme might not be applicable to
representations returned by dereferencing the namespace name.


> This is no more than a V.001 strawman, but at this point I kind of like 
> it.  Feedback?
> -- 
> Cheers, Tim Bray
>         (ongoing fragmented essay: http://www.tbray.org/ongoing/)

Received on Monday, 31 March 2003 05:00:12 UTC