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

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| Norman Walsh writes:
|> 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.

Fixed.

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

Ok, I put that back and reworded.

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

Indeed. (While you're hacking standard-components.xml... :-)

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

I added the following to the end of the first paragraph in the
Syntax Overview section:

  XProc is intended to work equally well with <biblioref
  linkend="xml10"/> and <biblioref linkend="xml11"/>. Unless otherwise
  noted, the terms “XML” and “Namespaces in XML” refer equally to both
  versions. Support for pipeline documents written in XML 1.1 and
  pipeline inputs and outputs that use XML 1.1 is
  <glossterm>implementation defined</glossterm>.

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

I didn't think we *were* treating them specially. It seems to me
that allowing an output port to be bound to an input port *would be*
treating it specially. I'm confused.

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

Ok.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | There are infinite possibilities of
http://nwalsh.com/            | error, and more cranks take up
                              | unfashionable untruths than
                              | unfashionable truths.--Bertrand Russell