W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > August 2008

Re: rdf accommodation

From: Paul Tyson <phtyson@sbcglobal.net>
Date: Wed, 20 Aug 2008 22:23:41 -0500
Message-ID: <48ACDFBD.8020803@sbcglobal.net>
To: public-xml-processing-model-comments@w3.org

Norm, thanks for your considerate response.

I re-read the Xproc WG charter and it plainly defines the scope as "XML 
processing".  But the wording leads me to believe RDF was omitted 
accidentally, not excluded deliberately.  I wasn't there, so I don't know.

History aside, I believe it would advance the art greatly to include 
p:sparql and some friends in XProc 1.0.  The global amount of RDF 
processing will only increase in the future, and a good deal of this 
will involve shape-shifting between RDF and XML.  Xproc is an ideal tool 
for this.

Equipped for RDF processing, XProc will become a veritable sorcerer's 
apprentice for processing structured and semantic data.  What about 
adaptive xproc that rewrites itself to adapt to changing circumstances? 
  Xproc scripts that write the xslt and sparql that they then use?  Once 
you have a program that can write programs the possibilities are 
endless.  But launching XProc without standardized RDF processing will 
slow the development of these sorts of applications.


Norman Walsh wrote:
> / Paul Tyson <phtyson@sbcglobal.net> was heard to say:
> | Did the WG consider including some standard step definitions for RDF
> | processing?  At minimum, an optional p:sparql analog to p:xslt seems
> | reasonable.  Beyond that, some convenience definitions for simple
> | graph modifications would enable RDF processing comparable to what is
> | now provided for XML processing.
> It's difficult to judge how wide the XProc WG should cast its net in
> search of optional steps. As chair, especially now, my instinct is to
> do everything reasonable to limit rather than extend our current
> scope.
> That said, a p:sparql step doesn't seem like a bad idea, but I fear
> the same could be said for two, three, ten, perhaps a hundred other
> steps.
> | RDF processing steps can easily be defined and implemented by 3rd
> | parties, using the existing framework.  But I expect there will be a
> | proliferation of variant definitions that will impede portability of
> | xproc scripts for RDF processing.
> I hope that exproc.org (like exslt.org) will help the community adopt
> standard signatures for popular steps. Not that I've done much with it
> yet.
> | Perhaps the step definitions for RDF processing could be specified in
> | a profile or module so that existing implementations will not be
> | affected, and future implementations can choose whether to support
> | them.
> I think that it would be great if a community of RDF users and
> implementors wanted to define a collection of RDF-related steps.
> Speaking strictly for myself, I'd even be willing to propose that such
> a document be published as a WG Note.
>                                         Be seeing you,
>                                           norm
Received on Thursday, 21 August 2008 03:22:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:25 UTC