Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: equivalentTo vs. XSLT
 > > I'll try again: once you've defined an executable > transformation (eg. > > using XSLT), what useful job is there left for RDF/DAML/OWL to do? > > Probably none. But I wouldn't define an executable > transformation in an > XSLT program when I could define a declarative mapping in a > single line of OWL. > There are many valid ways of doing transformations other than XSLT, and I haven't followed the thread that led to this, so I'm not sure what it's being compared with here, but there are a few assertions made here that I think need to be picked up on. > First, the XSLT is Turing complete. That means that if you > send an agent > onto the Web to find an XSLT that translates ebXML into BizTalk, you > have no idea what computational resources you are committing > to run the > transformation it finds. You can't even kill the process with > confidence > when it runs in an "unreasonable amount of time" because > perhaps it was > just one second away from completing the task. So you set > some arbitrary > runtime limit and take your chances. I *believe* that the > computational > properties of semantic web reasoners are more predictable. > But I am not > a computational logician so I could be wrong on that. I think there are very few technologies that allow this kind of predictability. For example, SQL performance is pretty difficult to predict even though (core) SQL is not computationally complete. In fact, I think that you need to limit the expressive power of a technology very severely indeed if you want this feature. > > Also, there are issues around security and analysis of > Turing-complete > programs versus declarative specifciations. And serious optimization > issues! So overall, I see the OWL route as being more > reliable, secure and performant. Apart from denial-of-service risks, security has nothing to do with Turing completeness, it's to do with the external resources that a an executable has access to. From this point of view, XSLT is very clean. It's also very clean from an optimization point of view, in that being side-effect-free, it's very amenable to rewriting in the same way as SQL. Of course, a language with less functionality will generally do the same job faster than a language with more functionality. > > Second, the XSLT specification has weak support for handing > off from one > XSLT to another on a very granular (per-element) basis. Consider: > > Input: > > <some-ns:coffee> > <some-ns:hot/> > <your-ns:sweet/> > </some-ns:coffee> > > Wished-for Output: > > <my-ns:drink> > <my-ns:temperature>hot</my-ns> > <my-ns:sugary/> > </my-ns:drink> > > I need to be able to switch mapping specifications's midstream from > some-ns->my-ns to your-ns->my-ns. I'm having a hard time > envisioning how > I would do this in XSLT, but I think it is standard in logic > languages. > (Prolog calls it unification, but I think the Prolog algorithm is > probably more powerful than is needed for OWL) I don't see the problem here. The apply-templates mechanism does exactly this. It's quite straightforward to combine two push-style stylesheets for different namespaces using xsl:import. > > Third, I've never heard of anybody composing XSLTs that were > developed > entirely independently except by building a pipeline where > the document > is processed by one and handed off to another. I'm not sure why you are deprecating the pipeline approach, it's extremely powerful. But I have seen other approaches, e.g. in preparing W3C specs for publication, we've recently combined a stylesheet that renders diff markup with another that renders BNF, these were developed quite independently of each other. <snip/> > > Fourth, it is much easier to use OWL as it was intended to be > used than > to chain-gang XSLT into the job. XSLT is not even designed to be a > "general-purpose transformation language" much less a > semantic mapping > language. > The XSLT 1.0 spec contains the statement that "XSLT is not intended as a completely general-purpose transformation language". But is it true? I have always surmised it was added at the end of a long and fruitless discussion about the scope of the language, to represent some kind of compromise between those who wanted the language to be general-purpose and those who wanted it to be small (and/or to focus on rendering applications). It's never been clear to me whether the idea was to justify the inclusion of features that aren't general-purpose (like attribute sets and xsl:number), or to justify the exclusion of features that are general-purpose (like functions and regular expressions). Either way, I regard it as a political statement (or perhaps a historical one), not as a technical statement about properties of the language. Michael Kay Software AG home: Michael.H.Kay@n... work: Michael.Kay@s... 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
