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

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

Norman Walsh writes:

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


OK, but

 a) c:error links to the anchor 'c.error', which is on 7.1.7 in the
    document: it should linke to 'cv.error';

 b) <err:error> still occurs in Example 9 in 4.6.2.

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

Well, I thought the tableau for other_atomic_step was useful -- why
did you remove _it_?  And there's still the sentence "Other steps can
be atomic or compound", followed by a discussion of atomic, but
nothing about compound. . .

> | 5.5
> |
> |   A note about security implications?
>
> Such as?

   "Note: This element represents a potential security risk: Running
   unexamined 3rd-party pipelines could result in vital system
   resources being overwritten."

Something similar probably belongs in 7.1.23 Store.


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

Well, I probably meant "[Namespaces 1.0] or [Namespaces 1.1], as
appropriate", but both you and I are assuming something in document
about 1.0 vs. 1.1 flexibility, which isn't actually there yet, as far
as I can see. . . 
> | 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.

Sigh -- I don't see why we should treat these specially, but I don't
suppose it makes much difference.  If no-one else cares, I'll let this
go.

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

Ah, _that's_ the point.  Well, it can't be a document, it can't
include a doctype. . .  I guess we need to be careful to say what we
really mean here:

   "It is a static error (err:XS0024) if the content of the p:inline
    element does not consist of exactly one element, optionally
    preceded and/or followed by any number of processing instructions,
    comments or whitespace characters."

I don't know how else to say this, since there is no notion of
well-formed infoset to appeal to, otherwise we could say "the content
. . . must be such as to produce a well-formed infoset when installed
as the [children] of a Document InfoItem".

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

See earlier response.

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)

iD8DBQFG1AsskjnJixAXWBoRApjJAJ9cfVUz7wrpMk357tJH2bcUFGVShQCeKNBV
GsxHRhxRbzFDThYCFFF4yvw=
=GWtw
-----END PGP SIGNATURE-----

Received on Tuesday, 28 August 2007 11:48:16 UTC