- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Fri, 07 Sep 2007 13:00:07 +0100
- To: public-xml-processing-model-wg@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have reviewed the relevant part of the current draft (section 2.2,
beginning with the definition of _namespace fixup_ [1]), and I actually
think it's excellent, and very nearly all that we need.
I don't think any change in overall substance is needed, just some
more detail, along the following lines
1) add some guidance after the paragraph which finishes "is also
conformant.", along the following lines:
Except where the specific semantics of a step explicitly require
changes, processors *must* preserve the information in the
documents and fragments they manipulate insofar as possible. In
particular, the information corresponding to the infoset
properties
[local name]
[namespace name]
[children]
[attributes]
[normalized value]
[parent]
[owner]
[base URI]
*must* be preserved. The information corresponding to
[prefix]
[in-scope namespaces]
[namespace attributes]
[attribute type]
*should* be preserved, with changes to the first three only as
required for namespace fixup. In particular, processors are
encouraged to take account of prefix information in creating new
namespace bindings, to minimise negative impact on prefixed names
in content.
2) We also have to modify what we say about serialization, as it at
least appears to contradict section 7.3 as it stands, because 7.3
allows the 'html' and 'text' serialisation methods to be invoked.
I think the para which begins "Whenever an implementation
serializes" as follows:
Whenever an implementation serializes pipeline contents, for
example for pipeline outputs, logging, or as part of steps such
as p:store or p:http-request, it is a *dynamic error* if that
serialization could not be done so as to produce a document
which is both well-formed and namespace-well-formed, as
specified in *XML* and *Namespace in XML*, regardless of what
serialization method, if any, is called for.
[Editorially, I note that the transition from this (mostly new)
discussion to the para. which begins "The common case" is pretty
awkward, and wonder of this discussion about what flows would sit
better in 2.6 Connections, leaving only the (modified as suggested
above) para which begins "Whenever an implementation serializes" in
2.2.]
There are at least two other kinds of 'fixup' we probably ought to
consider. At least p:insert[p:input[@port='insertion']/*/@select] and
p:unwrap might be understood as requiring xml:lang fixup, and at least
p:viewport, p:insert, p:unwrap, p:rename, p:wrap, p:set-attributes and
p:add-attribute may affect the consistency of xml:base and [base URI].
The XInclude REC has some potentially useful discussion [2] about
kinds of fixup. Once we agree about namespace fixup, we should add
something about these two.
On balance, I think we will end up wanting to include an _advisory_
list of steps which may provoke the need for each kind of fixup, or,
alternatively, adding standard boilerplate about fixups to every step
which needs one or more kinds.
ht
[1] http://www.w3.org/XML/XProc/docs/langspec.html#dt-namespace-fixup
[2] http://www.w3.org/TR/xinclude/#creating-result
- --
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
Half-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFG4T1HkjnJixAXWBoRAm8OAKCD5NF29jEMudDSHxEQ3c/Z42cdbACdEeNB
bSHRuv2pz8kj6oMSTeRlHik=
=/DX8
-----END PGP SIGNATURE-----
Received on Friday, 7 September 2007 12:00:19 UTC