RE: Review of WSDL 2.0 - RDF Mapping

My 2 cents, if it's worth anything:

I'd be a bit nervous about making the XSLT normative and the prose
non-normative.  There are simply too many opportunities for bugs and
unanticipated edge cases in an XSLT, and too many opportunities to
desire fine-tuning or repurposing to make a Recommended XSLT terribly
useful.  It smells far too much like a reference implementation rather
than a specification.  XSLT has many quirks which a mapping would
inevitably use that might make it difficult to translate to other
languages.  I think an XSLT would be a great idea but I would be very
nervous about asserting that it is appropriate for absolutely every
case.  XSLT immediately falls down if there aren't (for example)
accurate xsi:schemaLoacation attributes to direct the importing of
schemas, which attributes are optional hints per the spec.

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
On
> Behalf Of Booth, David (HP Software - Boston)
> Sent: Tuesday, January 17, 2006 3:16 PM
> To: Jacek Kopecky
> Cc: Bijan Parsia; WS-Description WG
> Subject: RE: Review of WSDL 2.0 - RDF Mapping
> 
> 
> Jacek,
> 
> > From: Jacek Kopecky [mailto:jacek.kopecky@deri.org]
> > . . .
> > 1) A component with a known extension is mapped according to
> > the rules specified by the extension.
> 
> Yes, that makes sense.
> 
> > 2) A component with unknown optional extension is mapped as
> > if the extension wasn't there (we assume optional extensions
> > don't change the
> > semantics) and the extension is added there as XMLLiteral (or
> > as string literal for extension attributes)
> 
> Oh, I see.  Sort of like a null mapping?  I.e., whatever was given in
> the WSDL is what you get in the RDF?  I see.  That seems like a good
> default way to map unknown optional extensions, as it at least gives
you
> something in the RDF that corresponds to the extension.  I was not
> assuming that you would provide such a mapping, but it seems like a
good
> idea.  I was assuming that if you wanted the resulting RDF to contain
> information about the optional extension then you would use an
> additional mapping specifically for that extension.
> 
> > 3) A component with unknown mandatory extension is not mapped at
all.
> >
> > The XSLT that we can provide will know the extensions for the
> > bindings etc., but it won't know any user extensions. I'm not
> > sure how to make it extensible, so that users would be able
> > to plug in their stylesheets for components with the
> > extensions that they know. I suspect it'll be easier for such
> > user just to tweak our stylesheet than to try to plug into
> > our extensibility points.
> 
> I'm a little nervous about users modifying your main stylesheet for
> optional extensions, because that makes it seem like they may be
> modifying the overall semantics (such as for with mandatory
extensions).
> 
> Here is what I would envision for XSLT stylesheets:
> 
> A. Basic Mapping.
> 	Domain: WSDL.  Range: RDF.
> 	Maps WSDL and known extensions to RDF.
> 
> B. Default Optional Extension Mapping.
> 	Domain: WSDL.  Range: RDF.
> 	Maps optional extensions to RDF (just a null mapping).
> 	Resulting RDF should be combined with the RDF produced
> 	by the Basic Mapping.
> 
> C. Mapping for Optional Extension X.
> 	Domain: WSDL.  Range: RDF.
> 	Maps optional extension X to RDF.  Resulting RDF should
> 	be combined with the RDF produced by the Basic Mapping.
> 	Users would probably create this mapping
> 	by modifying the XSLT for the Default Optional
> 	Extension Mapping.
> 
> D. Mapping for Mandatory Extension Y.
> 	Domain: WSDL.  Range: RDF.
> 	Maps WSDL, known extensions and extension Y to RDF.
> 	This mapping would be used instead of the Basic
> 	mapping.  Users would probably create this mapping
> 	by modifying the XSLT for the Basic Mapping.
> 
> And of course, you would only provide A and B.  Users would supply C
and
> D if desired.  Does this make sense?  Is this different from what you
> were thinking?  I'm just trying to understand what you mean and
> reconcile it with what I was expecting.
> 
> Thanks,
> David Booth

Received on Tuesday, 24 January 2006 20:50:12 UTC