W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2004

RE: XHTML and RDF; thinking about Trix, etc

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Fri, 27 Feb 2004 12:55:29 +0100
To: "Victor Lindesay" <victor@schemaweb.info>, "'Jeremy Carroll'" <jjc@hplb.hpl.hp.com>, <www-rdf-interest@w3.org>
Message-ID: <BHEGLCKMOHGLGNOKPGHDAEMACCAA.jjc@hpl.hp.com>



XSLT 2.0 helps because it has an appropriate sort. The sort in XSLT 1.0 has
some implementation dependent features. The sort is needed for handling
rdf:parseType="Literal".

I have implemented an XSLT rdf parser - it is incredibly slow - and is based
on an older version of the syntax doc, I can't quite remember what it can't
do, I imagine everything it couldn't do has now been scratched. However, at
that time we did not have clarity about parseType="Literal" so it just
treated that as an unproblematic blob - inappropriately.

I guess we hadn't done datatypes ...

My parser can be found at

http://www-uk.hpl.hp.com/people/jjc/snail/

Features:
+ Glacial, even with the fastest CPU
+ Excessive use of temporary disk space
+ Pathetic error detection
+ Non-conformant N-Triples output.

I agree hold heartedly that one shouldn't be using this approach in anger.
However, Snail had other objectives:

And .
+ XSLT based, tree transforming, RDF/XML to N-triple converter.
+ Principled non-deterministic use of abbreviation rules.
+ Detailed derivation trail for every parse.

which made it even slower.
(Legal advice suggested I should not claim that it was the world's slowest
RDF/XML parser!)

So - the point about the XSLT as backward compatibility is that the approach
allows each data document to be marked with a pertinent transform -
obviously for performance sake the most common ones of any complexity (e.g.
for RDF/XML) should have special high-performant implementations, which
by-pass the normal mechanism - but the normal mechanism will work. Thus if
TriX moves forward it is important to have a known and preferred URL with
the RDF/XML transform in, and then production TriX systems would simply feed
such files straight into an RDF/XML parser. But when coding a TriX system up
from scratch it starts to work before you decide which RDF/XML parser to
use.

Jeremy









> -----Original Message-----
> From: Victor Lindesay [mailto:victor@schemaweb.info]
> Sent: 27 February 2004 12:22
> To: 'Jeremy Carroll'; www-rdf-interest@w3.org
> Subject: RE: XHTML and RDF; thinking about Trix, etc
>
>
> Jeremy Carroll wrote:
> > One way that TriX might replace RDF/XML is, once we have XSLT
> > 2.0 and a
> > transform from RDF/XML into TriX (all doable), it is trivial
> > to migrate an
> > RDF/XML document into TriX (a one line change, adding a processing
> > instruction).
>
> Hi Jeremy,
>
> How does XSLT 2.0 help the RDF/XML to TriX transform. What advantage
> does it have over XSLT 1.0 to perform this task? And shouldn't we be
> using a parser rather than an XML technology to process raw RDF/XML? My
> practical experience is that XSLT cannot reliably read triples. We might
> get close but the XSLT gets so horrendously complicated and
> unmaintainable that it not worth using.
>
> Show me a stylesheet that purports to extract triples with 100%
> reliability and an example RDF/XML instance and I am sure that even I
> with a limited knowledge of the RDF Syntax spec could produce an
> identical instance (same triples) that would break it.
>
>
>
>
>
Received on Friday, 27 February 2004 06:55:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:58 UTC