Re: rdf accommodation

/ 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

-- 
Norman Walsh <ndw@nwalsh.com> | Through space the universe grasps me
http://nwalsh.com/            | and swallows me up like a speck;
                              | through thought I grasp it.-- Pascal