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

Comments on August 22 editors' draft from section 4.3 through 7 intro

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Mon, 27 Aug 2007 15:31:00 +0100
To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
Message-ID: <f5bejhp6od7.fsf@hildegard.inf.ed.ac.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

4.3.1

 Same change to 'Note to implementers' as for 4.2.1

4.3.2

  "add an hr element before all"
 -->
  "add an hr element at the beginning of all

4.4

  "same number outputs" --> "same number of outputs"

4.6.1

  Major confusion wrt prefixes (c: vs err:) and links (c:error in the
  first liine of 4.6.1.2 links to the p:error section!)

  I have some vague memory of a decision to abandon a namespace and
  collapse names from that namespace into some other one -- was it the
  err: namespace?  If so, not only do the uses of err: in this section
  and in 4.6.2 need to be changed, but also the entry for err: should
  be removed from section 3.1

4.6.2

  Examples --> Example
  (oops, and in 4.1 -- 4.5 subsections as well . . .)

4.7

  As long as we leave the tableau for them here, we can't say
  _nothing_ about other-compound-steps!  I would prefer to see them
  removed from this section (see previous discussion), since they have
  to be extensions, and as such they don't have to conform to our
  syntax at all (note for instance that as written the production
  given here would rule out a p:choose-type extension,
  e.g. ipfx:case).

  At the very least, we need something along the lines of "The
  'other-compound-step' tableau is included above as an illustrative
  place-holder for future expansion of the language, which might be
  explored via extensions in the first instance."

5.1.1

  I think it's worth including something along the lines of

  "It is a *static error* if the declaration of a document input port
   inside a p:declare-step contains bindings; document input port
   declarations must be empty unless they are declaring _and_ binding
   an input port for a p:pipeline."

5.1.2

  The wording here for ruling out content need not mention 'default',
  as it's never been suggested that there _was_ a default:

  "It is a static error (err:XS0035) if the declaration of a
   parameter input port contains bindings; parameter input
   port declarations must be empty."

 ------

  I think it's a mistake to use the concept of 'extension attributes'
  for elements in the c: namespace -- it's not at all obvious what
  specification of extension namespaces should be appealed to (at
  runtime, note), to determine this.  Wouldn't it be easier to say,
  for c:parameter:

   "Any namespace-qualified attribute names that appear on the
    c:parameter element are ignored; it is a *static error* for any
    _un_qualified attributes other than 'name', 'namespace' or 'value'
    to appear."

  and for c:parameter-set, either the same, or just:

   "Any attribute names that appear on the c:parameter element are
   ignored"

5.4

  The primary stuff should be brought in to line with 5.1.1 (and 2.3):

  "The primary attribute is used to identify the primary output
   port. An output port is a primary output port if primary is
   specified with the value 'true' or if the step has only a single
   output port and primary is not specified. It is a static error
   (err:XS0014) to specify that more than one output port is the
   primary."

5.5

  A note about security implications?

5.7

  "Options names" --> "Option names"

5.7.1.1

  Sigh, this highlights a general problem.  We use 'QName' all over
  this spec., and sometimes we specify in detail where the namespace
  bindings come from to expand them (most notably for option values,
  but also, e.g. for c:parameter names), in which case one should
  understand QName to mean "QName as specified in XML Namespaces 1.1".
  But in other places, e.g. here, we just say "must be a QName".
  _Either_ we should specify where the namespace bindings come from,
  _or_ we should say "must be a QName as specified in XML Schema 1.0"
  (but that wouldn't _really_ do that job, because the Schema spec. is
  weak here).

  I guess I think we should make QName a defined term, use it
  everywhere, and define it to mean "must be a QName as specified in
  XML Namespaces 1.1.  If unprefixed, in no namespace.  If prefixed,
  prefix *must* be bound in the in-scope namespaces of the containing
  element, unless some other source of namespace bindings is
  specified." and specify one or two static errors to use for failures
  of the two "*must*"s.

 ------

  "to specify that the option is both required and has a default
   value."

 -->

  "to specify that an option is both required and has a default
   value."

5.7.1.3

  "If a 'select' expression is given, ..."

  Should reference 2.8.1, and mention variable references, e.g.:

  "If a 'select' expression is given, it is evaluated as an [XPath
   1.0] expression using the Processor XPath context as defined above
   in section 2.8.1.  The [XPath 1.0] string value of the expression
   becomes the value of the option.  Since all in-scope options are
   present in the Processor XPath context as variable bindings,
   'select' expressions may refer to the value of in-scope options by
   variable reference.  It is a static error (err:XS0019) if a
   variable reference uses a QName that is not the name of an in-scope
   option."

 -----

  "If the value of an option is a constant, and no namespace bindings
   are necessary, its value may also be specified on the parent step
   as specified in Section 4.7.1, 'Syntactic Shortcut for Option
   Values'."

  Whoa -- I didn't agree to "and no namespace bindings are necessary" !

  Why can't we say that in that case the in-scope namespace bindings
  are used?  That's the default for <p:option value='...'/>, right?

  Or is what is meant

  "If the value of an option is a constant, and no namespace bindings
   other than those in-scope on the parent step are necessary, its
   value may also be specified on the parent step as specified in
   Section 4.7.1, 'Syntactic Shortcut for Option Values'."

  [out-of-band conversation with Norm suggests that is indeed what was
  meant, so this is just editorial after all]

5.7.2

 Combine the paras about 'select' before and after the tableau to give
 a para. identical to the one above for options, s/option/parameter/.

5.7.3

  "The p:namespaces element can be used to provide explicit
   bindings."

 -->

  "The p:namespaces element can be used as a child of p:option or
   p:parameter to provide explicit bindings."

 -----

 I find the discussion of what bindings a p:namespaces element
 contributes somewhat unclear.  How about replacing the two paras
 which are there at present with the following:

  "The namespace bindings specified by a p:namespaces element are
   determined as follows:

    1) All the bindings defined by explicit namespace attributes
       (other than 'xmlns') on the p:namespaces element itself are
       used;

    2) If the 'option' attribute is specified, it *must* contain the
       name of a single in-scope option. The namespace bindings
       associated with that option are used;

    3) If the 'element' attribute is specified, it *must* contain an
       XPath expression which identifies a single element node (the
       input binding for this expression is the same as the binding
       for the p:option or p:parameter which contains it). The
       in-scope namespaces of that node are used;

    4) The except-prefixes attribute can be used to exclude one or
       more namespaces from the set determined by the previous three
       bullets. The value of the except-prefixes attribute *must* be a
       sequence of tokens, each of which *must* be bound to a
       namespace in the in-scope namespaces of the p:namespaces
       element.  All bindings of prefixes to each of the namespaces
       thus identified are excluded."

    and then the XS0005 and XS0041 error specs.

5.10

 'Name' is overloaded -- I think at the very least we need to change

  "It is a dynamic error (err:XD0012) to import more than one
   pipeline with the same name or type (either directly or within a
   library)."

- -->

  "It is a dynamic error (err:XD0012) to import more than one
   pipeline with the same expanded name (either directly or within a
   library)."

 which sort of implies a definition further up:

  "The [expanded name] of a pipeline is the expanded name denoted by
   its type, if it has one, otherwise the expanded name specified by
   the namespace of its containing pipeline-library and its name."

5.11

 I'm unhappy with a perhaps-unintended consequence of the way output
 ports on compound steps are handled here.  Seems to me this is a
 perfectly good p:for-each:

  <p:for-each name="saveThem">

   <p:output port="result">
    <p:pipe step="saveThem" port="current"/>
   </p:output>

   <p:save>
    <p:option name="href" select="concat("file:/tmp/chapter",
                                         p:iteration-position(),
                                         ".xml")/>
   </p:save>

  <p:for-each>

 I would propose therefore that we change the discussion of
 constraints on p:pipe binding to read as follows:

  "In all cases except the p:output of a compound step, it is a
   static error (err:XS0022) if the port identified by a p:pipe is not
   in the readable ports of the environment of the step that contains
   the p:pipe. [unchanged]

  "It is a static error (err:XS0022) if the port identified by a
   p:pipe in the p:output of a compound step is not in the readable
   ports of the _inherited environment_ for steps contained in that
   compound step.

  "In other words, the output of a compound step is treated like the
   input of a new final step in its subpipeline. All other bindings
   must be to ports that are already readable in the current
   environment."

 I prefer this not only because it fixes what I think is a bug, but
 also because it makes the defaulting of compound outputs follow
 naturally.

5.12

  "It is a static error (err:XS0024) if the content of the p:inline
   element is not a well-formed XML document."

 How could any processor ever detect this error?

5.13

  "The parser which the p:document element employs must be conformant
   to Namespaces in XML.

 -->

  "The parser which the p:document element employs must be conformant
   to [Namespaces 1.1]."

6

 I didn't check this section, on the assumption that its prose is
 autogenerated from the locus of first use. . .  Maybe that's false?

7

  "The base URI of the output is the base URI of input document
   unless the step's process explicitly sets and xml:base attribute or
   the step's description explicitly states how the base URI is
   constructed."

 -->

  "The base URI of the output is the base URI of the step's primary
   input document unless the step's process explicitly sets an
   xml:base attribute or the step's description explicitly states how
   the base URI is constructed."

 [one substantive change and one typo]

 Is it in fact the case that all builtin steps have a primary input or
 specify their output's base URI?  Should we add something such as


  "If the step has no primary input document, its description *must*
   state how the base URI is constructed."

 -----

  "When a step uses an XPath from an option value, the XPath context
   is as defined in Section 2.8.1, 'Processor XPath Context'."

 -->

  "When a step uses an XPath from an option value, the XPath context
   is as defined in Section 2.8.2, 'Step XPath Context'.

ht
- -- 
 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)

iD8DBQFG0uAkkjnJixAXWBoRAjChAJ9U3gmUTMRCdHnwPatMjZNK2OwjEwCfZGST
WNs4Oirrx734fdkPU5qvlwo=
=Aohu
-----END PGP SIGNATURE-----
Received on Monday, 27 August 2007 14:31:12 GMT

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