W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > September 2007

towards consensus on fixup, part 2

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
Message-ID: <f5b4pi6heig.fsf@hildegard.inf.ed.ac.uk>

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:54 GMT