RE: Review of WSDL 2.0 - RDF Mapping

Hi Jacek,

Optional extensions should work very cleanly with the XSLT approach.
Each extension can be defined by supplying a separate XSLT script that
produces additional RDF that is then merged with the RDF produced by the
normative mapping, because an optional extension does not invalidate the
existing semantics.  Very clean.

I think mandatory extensions would mean that a new XSLT script would
have to be supplied by the person defining the mandatory extension,
because mandatory extensions by their very nature have the ability to
change the existing semantics.  I don't see any way around that.

David Booth


> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek.kopecky@deri.org] 
> Sent: Friday, January 13, 2006 4:14 AM
> To: Booth, David (HP Software - Boston)
> Cc: Bijan Parsia; WS-Description WG
> Subject: RE: Review of WSDL 2.0 - RDF Mapping
> 
> 
> David, 
> 
> the WG has not yet agreed to produce any XSLT, but this 
> shouldn't be a problem. There may be scheduling concerns, though.
> 
> There might be a problem with extensions, though - the 
> normative XSLT will only understand the extensions that are 
> defined in our WSDL specs, and won't be able to handle WSDL 
> files with other extensions, especially mandatory extensions. 
> I'm afraid making the XSLT extensible out-of-the-box with 
> stylesheets for handling extensions would be an overkill, so 
> anybody who will want to map their extensions into RDF will 
> have to come up with their version of the XSLT as well. In 
> this regard the XSLT would be limited and I'm not sure if it 
> can be the normative mapping then.
> 
> There will be an XSLT, I'm just not sure yet about its status 
> - one of the implementations, informative stylesheet or the 
> normative mapping.
> 
> If you have any thoughts how we could handle extensions here, 
> please let me know. 8-)
> 
> Best regards,
> 
> Jacek
> 
> On Thu, 2006-01-12 at 15:28 -0500, Booth, David (HP Software - Boston)
> wrote:
> > Hi Jacek,
> > 
> > So if I'm understanding correctly, you do intend to provide an XSLT 
> > version of the WSDL 2.0 --> RDF mapping, but you want the English 
> > prose to be based on the WSDL 2.0 component model, right?
> > 
> > In that case, I would suggest making the XSLT version be 
> the normative 
> > definition of the WSDL 2.0 --> RDF mapping, and have the 
> English prose 
> > act as ancillary explanation.  That way I would see no problem with 
> > the English prose being based on the component model.  And defining 
> > the mapping in terms of XSLT would give much greater precision than 
> > English prose, because it is a formal, machine-processable language.
> > 
> > I think this would be a more direct and useful approach, because it 
> > would not require users to come up with their own 
> interpretations of 
> > the English prose.  Is there some reason why you think such an 
> > approach would not work or not be feasible?
> > 
> > David Booth
> > 
> > 
> > > -----Original Message-----
> > > From: Jacek Kopecky [mailto:jacek.kopecky@deri.org]
> > > Sent: Wednesday, January 11, 2006 9:16 AM
> > > To: Booth, David (HP Software - Boston)
> > > Cc: Bijan Parsia; WS-Description WG
> > > Subject: RE: Review of WSDL 2.0 - RDF Mapping
> > > 
> > > 
> > > Hi David, Bijan,
> > > 
> > > in the English prose specifying the mapping, I prefer
> > > strongly to come from the component model, because the 
> > > component model is not a simple 1:1 lifting of the infoset, 
> > > it contains rules like defaulting that make multiple WSDL 
> > > documents equivalent even if they aren't the same. Basing the 
> > > RDF mapping spec on the component model gives us 
> > > automatically all these things, whereas if we were based on 
> > > the infoset (or even XML bytes, would you say?), we'd have to 
> > > reiterate in some form at least the defaulting rules from the 
> > > WSDL 2 spec.
> > > 
> > > In fact, if somebody creates an API for accessing and
> > > manipulating WSDL 2 documents, I expect it should follow the 
> > > component model, too. So while I also see specs as software 
> > > boundaries, I actually see the component model as a software 
> > > API. This API would provide to the applications the 
> > > defaulting functionality (and the rest of what the component 
> > > model specifies) - the defaulting rules should not be 
> > > implemented in every WSDL-aware application, don't you agree? 8-)
> > > 
> > > As I said, an XSLT (most probably) will be produced as an
> > > implementation of the mapping, and this XSLT will naturally 
> > > work from the XML form of WSDL. But I expect the things like 
> > > defaulting to be implemented in the XSLT or in rules within 
> > > the ontology (if we have the technology by then), and not in 
> > > the consumer of the RDF form.
> > > 
> > > Hope this clarifies my thinking,
> > > 
> > > Jacek
> > > 
> > > 
> > > 
> > > On Mon, 2006-01-09 at 15:28 -0500, Booth, David (HP Software - 
> > > Boston)
> > > wrote:
> > > > Comments below.
> > > > 
> > > > > From: Bijan Parsia [mailto:bparsia@isr.umd.edu]
> > > > > 
> > > > > On Jan 3, 2006, at 6:18 PM, Booth, David (HP Software 
> - Boston)
> > > > > wrote:
> > > > 
> > > > > > [snip]
> > > > > >> We intend to have the mapping from the component model to 
> > > > > >> RDF,
> > > > > >> not
> > > > > >> directly from the XML.
> > > > > >
> > > > > > Oh.  How would that work?   Given a WSDL 2.0 document, what 
> > > > > > would I do to produce the corresponding RDF?
> > > > > >
> > > > > > It sounds like you are saying that there would be two 
> > > > > > mappings, A and B, and you will be doing mapping B:
> > > > > >
> > > > > >                     A                               B
> > > > > > WSDL 2.0 document -----> WSDL 2.0 component model -----> RDF
> > > > > >
> > > > > > Is that what you mean?
> > > > > [snip]
> > > > > 
> > > > > Yes. So you have to look at the main specs to figure 
> out how to 
> > > > > get the component model from the xml, then the mapping to get 
> > > > > the rdf for that component model.
> > > > > 
> > > > > (Obviously, in code, you could do it directly once you've
> > > figured it
> > > > > out.)
> > > > 
> > > > Although I think this makes obvious sense as an internal
> > > strategy, I'm
> > > > a little uneasy with the idea that you would only be specifying
> > > > mapping B in the published mapping document.
> > > > 
> > > > Basically, I think of specs as corresponding to software
> > > boundaries,
> > > > and I think of the WSDL 2.0 component model as being a
> > > mechanism that
> > > > is internal to the WSDL 2.0 spec, as a convenient aid in 
> > > > specifying
> > > > the WSDL 2.0 language, rather than something that is 
> intended for 
> > > > external use.  Thus, defining only mapping B feels kind of like 
> > > > accessing directly into the middle of a piece of software 
> > > instead of
> > > > using its published interface.
> > > > 
> > > > More pragmatically, since the WSDL 2.0 --> RDF mapping 
> is from one
> > > > machine-processable language to another, I was assuming 
> > > (hoping?) that
> > > > the mapping itself would be also defined in a 
> machine-processable
> > > > language (such as XSLT for example).  Doing so would both 
> > > allow others
> > > > to use it directly (instead of having to implement their
> > > own mapping
> > > > software), and it would eliminate ambiguity that often
> > > appears in an
> > > > English prose specification of the mapping (though of 
> course there
> > > > could still be ambiguity in the meaning of the resulting RDF).
> > > > 
> > > > In short, I think it will be substantially more valuable if
> > > you define
> > > > the WSDL 2.0 --> RDF mapping in a machine-processable language.
> > > > 
> > > > David Booth
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> 
>

Received on Friday, 13 January 2006 18:24:14 UTC