Re: XProc Minutes: 8 Apr 2010

On Fri, 2010-04-09 at 12:08 -0800, murray wrote:
[...]
> I expected a pipeline that prescribed an order for a core
> set of XML processors, starting with well-formed xml
> processing and followed by (in some order) GRDDL
> interpretation, entity expansion, id validation, xml
> validation, namespace management, xinclude expansion,
> schemata validation and so on. I expected to have a model
> that prescribed or described when and where decryption and
> digital signature processing occur. I expected that for each
> step, the spec would provide reasoning for the position in
> the order as relates to building the infoset. I expected the
> pipeline, or library of pipelines, to provide for the
> ability to snif a document to determine whether it is
> eligible for processing, either by way of processing
> instructions a la XSLT, or through well-understood info
> items such as the GRDDL signature.

It look like this is a comment about the "default pipeline".
If not, ignore the rest of this message! But here's a little
background to the "default" question, in case it's of use. I
haven't been involved in discussions, so I'm not trying to steer
the WG in a particular direction, so much as to say, "this is
the question the W3C staff was trying to ask"...

The original mandate (when I wrote the charter) was much smaller
than Murray's list. Our question could be rephrased as,
    "In the absence of any specific information as to how a
     particular XML document should be processed, is there
     a default way to process it that always makes sense?"

For my part the answer to that question is "no". I could want
xml:include processing after schema validation, for example, because
I'm getting xinclude attributes from the schema. Certainly I
wouldn't want to see a statement from W3C that said, "you _must_
always processes XML documents as follows unless there is an
XProc pipeline embedded in the document." Even a "should" would
make me uncomfortable.

Actually the original question Tim asked was, what's the "meaning"
of an arbitrary XML fragment. But it became clear that he meant
behavioural meaning, that is, what set of operations is one
licenced by the various W3C XML specifications to perform on a
document, absentia other instructions. My own answer to that was
and remains that any XML processor is free to process any XML
document in any way it sees fit, at least from the point of view
of the specifications - I call that the "XML Promise." But that
was a personal response, not the result of a Working Group, and
also conflicted strongly with Tim's "Design Issues" idea that,
for example, an SVG document could be thought of as a function
that produces a rendered graphic when fed to an SVG renderer.
My take is that the SVG renderer could be a function, but that the
SVG document is input data to it. I suppose there is value in
both ways of looking at it. But that still leads me to say that
there's no universal default.

However, specifying a default behaviour for an XProc processor
in the absence of a pipeline seems to me entirely reasonable,
and could be argued to define the sort of default behavioural
semantics Tim wanted. Certainly, like Murray, I'd expect to
see where W3C XML Schema validation fitted into that picture,
as well as xml:base, xml:id, entity expansion (that one's easy),
and xinclude. That's a little less ambitious than Murray's list,
partly because I think the specs outside the W3C XML Activity
need to build on what we do, not interweave themselves into the
middle of it, so the answer for the rest is "after the default
pipeline has finished."

Best (and sorry not to have sent this earlier, this week has been
a bit hectic here!)

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org www.advogato.org

Received on Friday, 16 April 2010 03:01:18 UTC