RE: SYNTAX: RDF Syntax Telecon Friday

Minor points, then substantive comment in following e-mail.

> 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

Brian first suggested XSLT to me ..., which I had been resisting, due to its
syntax and not knowing it etc.

>   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.

I hope this step is unnecessary. (1) + (2) should only produce (3).


(3') Process aboutEach
   This special abbreviate form is quite different from the others and needs
to be processed last. Probably still can be done in XSLT?



>
> 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 would rather mutter about defects in an XSLT basic RDF/XML=>Ntriple
converter than to invent yet another language for RDF.


>
> It would give a strong hint to parser writers of how the
> implementation could be done and would quite programmer-friendly;


The greatest programmer-friendly spec is one which is specific not one that
is directly implementable. The problem with the old spec was not that it
didn't use programmer friendly ideas (such as EBNF) but that it is
self-contradictory. If we produce a contradiction-free spec, that at least
somebody can understand, then they can produce an equivalent "more friendly"
tutorial, if necessary.


Jeremy

Received on Tuesday, 2 October 2001 07:31:50 UTC