- From: Liam R E Quin <liam@w3.org>
- Date: Thu, 15 Apr 2010 23:01:13 -0400
- To: murray@muzmo.com
- Cc: Norman Walsh <ndw@nwalsh.com>, public-xml-processing-model-wg@w3.org
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