SYNTAX: RDF Syntax Telecon Friday

>>>Jan Grant said:

I'm cc:ing to w3c-rdfcore-wg, so please followup there.

> Any homework? Eg: look at (unpopular syntax representation mechanism X)
> before Friday?

Well, I want to concentrate on the syntax refactoring and mapping to
triples rather than issues such as "What is a Literal?", which is
coming along nicely in other threads :)

It would be good if you could review the stuff I referred to in
  http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Sep/0292.html
in respect to validating the RDF/XML syntax using various schema
languages.


I have been discussing some of this with Jeremy and my current
thoughts is an approach something like this.  Note this is not meant
to be the way that parsers are written, but the way that a formal
mapping RDF/XML->N-Triples can be defined that can be automatically
tested.

1) Validate the RDF/XML 1.0 (revised) syntax using existing
   XML schema language(s).

2) Remove abbreviated syntax forms

  This means getting rid of typedNodes, property attributes etc.

  I suggested to Jeremy to use XSLT and I think he has tried since he
  has named this the "Snail" approach, for its incredible
  performance.  DanC pointed out he had done some work in this
  area at: http://www.w3.org/2001/04rs22/

3) Validate the final form using a more strict schema definition as
   suggested by Henry Thompson and James Clark in messages linked
   above.

4) Use the final 'canonical' RDF/XML 1.0 to map into N-Triples using
   an XSLT transform to text/plain

   It would be something like sequences of
     <rdf:Description rdf:about="http://subject/">
	<foo:property>object</foo:property>
     </rdf:Description>

   Maybe.

   Of course this couldn't represent all legal rdf models, but will
   be able to do all models that RDF/XML 1.0 syntax can do.  Mutter
   ID, BagID, aboutEach ...

The alternative to the last step is to invent a real canonical form,
most likely a straight XML-ising of N-Triples.  I'd like to avoid
inventing another language unless absolutely necessary.


I'm also wondering about changing the style of the refactoring
notation for infoset items into something a bit more SAX-like i.e.
open_element(attrs)....close_element().

This would allow the current style to be rewritten as EBNF like the
previous grammar if all the grammar terminals were infoset items, and
the non-terminals expressed the rules to be matched.

It would give a strong hint to parser writers of how the
implementation could be done and would quite programmer-friendly; the
method to transcribing the parser into code would be more obvious.

In fact, my parser Raptor does that already with 'SAX' events
open_element(attrs), cdata(string), close_element so I can see a
close match to implemented code, which I always like.  I suspect the
Java SAX parsers also have a close match, which will help us get the
mapping to triples correct and quicker.

Dave

Received on Tuesday, 2 October 2001 06:10:12 UTC