Re: Clarification on proposed requirement

On Mon, Apr 15, 2002 at 06:50:41AM -0600, Uche Ogbuji wrote:
>  [On Fri, Apr 12, 2002 at 04:11:42PM -0700, David Booth wrote:]
> > Eric,
> >
> > The Web Services Description Working Group is seeking
> > clarification on your proposed requirement related to RDF support:
> >
> > "[Draft, Should, Semantic Web] All conceptual elements in WSDL
> > messages should be addressable by a URI reference. (Added 11
> > April, 2002.)"
> >
> > The group is concerned that this may require an ID attribute on
> > every conceptual element, which may be onerous.  Would it be
> > reasonable, for example, to reword this requirement as:
> >
> > "All conceptual elements in WSDL documents should be uniquely
> > addressable."
> >
> > For example, would it be adequate to require the qnames to be
> > unique?  Or are URIs specifically needed?

I believe unique qnames may as well be XML IDs (so long as they don't
collide with other XML IDs defined within the document). In this, they
create the fragment portion of a URI reference, which is the extent of
the intent my request.

It is possible that the wording of my request furthur constrains that
all WSDL documents be addressable by URI. This was not my desire.

> > [Can you give us a clearer explanation of the context of this
> >  proposed requirement?  A simple example would be great.]

Currently, in order to assemble the RDF model for a WSDL document, we
need to invent identifiers for some of the elements. If value of
/definitions@targetNamespace may provides the necessary unique
identifier for the document, all that is needed is a way to uniquely
invent names for elements (and the concepts they represent) inside it.
Three approaches spring to mind:

1. Define a mapping that invents names for these elements.

   This means that the mapping definition is asserting identifiers in
   the namespace. The inventor of the namespace 

2. Require that Namespace.LocalPart be unique and define the addressing
   of the elements in terms of Namespace.LocalPart.

   The places the burden of uniqueness on the WSDL generator.

   Processors aware of this recommendation and associated mime types
   will know of the existence of these URIs but generic XML processors
   will not. The "+xml" portion of mime type will not helpful and
   editors of WSDL documents will not be able to use XML editors to
   generate/enforce uniqueness of these names.

3. Require that the elements have an XML ID.

   This puts the same burden on the WSDL generator, but the resulting
   document is better understood by generic processors.

> > [(Incidentally, we are also assuming that the word "messages"
> >  should have been "documents".)]

Yah, sure, "document" sounds good, so long as it's not limited in
interpretation to HTTP. SOAP gets to use "message" to indicate mail
messages in parallel with web documents. It would be nice to preserve
this portion of the their semantics. Probably the XML 1.1 use of
"document" trumps the common association of documents with
web-available pages.

> As an interested outsider, I prefer the wording you suggest, David.
> I think that requiring the name attributes of WSDL elements to be
> unique would be sufficient.  I think it would be dangerous to fix on
> a particular system for ensuring this, because, unfortunately, ID
> attributes are in a bit of practical limbo these days.  Just making
> this a normative clause in the WSDL spec should do the trick.

I doubt that IDs are dead. The notion of having a schema/DTD enforced
document-wide unique identifier is central to many popular
applications, including XHTML. Whatever recommendation eventually
addreses this functionality will need to address XML 1.1 IDs. I would
like to use IDs so that our definitions addressed by such a
recommendation.

> From my POV, the important thing is to allow a clean and clear
> mapping from WSDL elements to RDF descriptions, and ensuring unique
> WSDL qnames would make things a bit smoother, ID type or no.

Indeed. I prefer IDs, but I'd be content either way.
-- 
-eric

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Monday, 15 April 2002 11:53:03 UTC