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

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

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 27 Aug 2007 13:29:56 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2sl64ansb.fsf@nwalsh.com>
/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| 4.3.1
|
|  Same change to 'Note to implementers' as for 4.2.1

Ok.

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

Ok.

| 4.4
|
|   "same number outputs" --> "same number of outputs"

Ok

| 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

The error vocabulary has been moved to the c: namespace, but the err:
namespace has been retained to identify static and dynamic errors.

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

Ok.

| 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."

Well, I removed the tableaus. Maybe that helps?

| 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."

Ok

| 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."

Ok.

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

I see your point. I'm happy to make this change.

| 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."

Done.

| 5.5
|
|   A note about security implications?

Such as?

| 5.7
|
|   "Options names" --> "Option names"

Fixed.

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

Do you mean "XML Namespaces 1.1" literally, or do you mean "XML Namespaces
1.0 or XML Namespaces 1.1, as appropriate"?

|  ------
|
|   "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."

Ok.

| 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."

Ok.

|   "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]

Yes. Fixed.

| 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/.

Ok.

| 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."

Fixed.

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

Ok.

| 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)."

Ok.

|  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."

Done.

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

That makes my brain hurt. Output ports bind to step outputs. If you
want that, stick in p:identity step that reads the input and produces
an 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?

By looking to see if p:inline has two or more top-level element children.

| 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]."

See earlier question about NS 1.0 vs. NS 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?

Egad! Yes! That's definitely true!

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

Fixed.

So we mean for a xml:base attribute on the root element to change the
base URI *of the document that contains that element*? That's not what
xml:base does ordinarily.

|  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."

Alex?

|   "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'.

Fixed.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It is better to waste one's youth than
http://nwalsh.com/            | to do nothing with it at all.--Georges
                              | Courteline

Received on Monday, 27 August 2007 17:30:06 GMT

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