Re: rdf accommodation

I must retract my suggestion for handling RDF in xproc. I had imagined 
xproc to be something it isn't.  What I had hoped for was something like 
"an XML vocabulary and syntax for defining pipelines to process various 
serializations of W3C-standard data instances".  But I see on closer 
reading that it is nothing like that.

Maybe it's not too far off, though.  Consider how a few simple changes 
would greatly expand the scope and power of xproc, without affecting its 
core XML processing capabilities:

1. Eliminate the requirement that says port-to-port data flow must be 
XML.  Instead, use some phrase that means "serialized data instance", or 
simply "data stream", a serialization of some data format specified by 
W3C.  (Actually, why shouldn't this just say "behave as if ...", instead 
of specifying the data stream?)
2. Provide a type-checking mechanism on input ports to report a dynamic 
error when a port receives data it can't handle (instead of just XD0001 
non-xml).  This could default to XML.

With these changes, xproc would be equipped to handle semantic 
processing of rdf, owl, or any other type of w3c data that has a non-xml 
syntax.

While the current draft addresses a large body of current mainstream XML 
processing, it fails to meet the growing need for combined syntactic and 
semantic processing.  I don't know of any other WG that aims to meet 
this need.  XProc has laid the groundwork for everything required in a 
pipeline language, so any separate effort for semantic processing would 
be largely redundant.

Thanks for listening.

--Paul

Norman Walsh wrote:
> / Paul Tyson <phtyson@sbcglobal.net> was heard to say:
> | 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.
> 
> To the extent that RDF/XML is XML, it's not omitted at all :-) More
> seriously, I don't think it was explicitly excluded, but I'm also not
> sure if I think it's really in scope or not.
> 
> | possibilities are endless.  But launching XProc without standardized
> | RDF processing will slow the development of these sorts of
> | applications.
> 
> I understand the desire to have all the important technologies in V1
> of a spec. I've also seen what happens if you let that goal drive the
> design process. Pretty, it's not.
> 
> Here's what I suggest: get some RDF folks together (I'm happy to be
> one of them) and work out what the fundamental building blocks for RDF
> support would be (what are the "and friends" in "p:sparql and
> friends"). Work out what their signatures would look like and spec
> them out.
> 
> If there are two or three, propose them as new optional steps during
> Last Call. If there are ten or fifteen, then let's see if we can get
> the WG to ratify them as a WG Note in parallel with the spec.
> 
> Even if they wind up in a WG Note, I promise to do my best to
> implement them. :-)
> 
>                                         Be seeing you,
>                                           norm
>

Received on Tuesday, 26 August 2008 02:29:21 UTC