Re: rdf accommodation

Paul Tyson <phtyson@sbcglobal.net> writes:

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

Well, I suppose it's a matter of perspective, but I think it's exactly
like that except that it processes the XML serialization of various
formats.

> 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?)

How would this expand its scope or power? Do you have in mind a
specific example of a use case that would be possible if the XML
constraint was relaxed but is not possible without relaxing it?

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

Allowing non-XML data would certainly introduce new interoperability
issues.

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

RDF and OWL both *have* XML syntaxes, so there's nothing about XProc
that's unable to handle them now. Surely the decision to send N3 or
RDF/XML through a particular pipe is an implementation detail that the
user doesn't care about.

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

I don't think the WG will consider expanding the scope in V1, though I
suppose it's a possibility in some future version. However, it will
have to be motivated by use cases that are prevented by the current
constraints.

I remain convinced that some RDF steps would be (will be!) valuable in
XProc, but aside from p:sparql, haven't heard any specific
suggestions.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Next to knowing when to seize an
http://nwalsh.com/            | opportunity, the most important thing
                              | in life is to know when to forego an
                              | advantage.--Benjamin Disraeli