- From: Jacek Kopecky <jacek.kopecky@deri.org>
- Date: Wed, 11 Jan 2006 15:16:18 +0100
- To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
- Cc: Bijan Parsia <bparsia@isr.umd.edu>, WS-Description WG <www-ws-desc@w3.org>
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 Wednesday, 11 January 2006 14:16:37 UTC