Review of Spec

* In §1, already the use of "component" in reference to the library of
standard "steps" is confusing.  Can't we just get rid of "component"
altogether and talk about steps?

* In §2.1, there is the statement:

  "(All steps have an implicit standard output port for reporting errors
that must not be
    declared.)"

  maybe that should be "implicit standard error port"?

* In §2.2, I don't understand the editorial note.

* In §2.5, there is a ambiguity between in-scope parameters and those
  that are imported.  §6.7 says:
  "All in-scope parameters which match the name are made available to the
step as if they had been specified with individual p:parameter elements."
  If they are in the in-scope parameters, they are already available.

  Do we need "in-scope parameters" and "actual parameters" ?


* In §3.3, I still disagree with the example using "encryption" when we
  do not have a component that does that at the current time.  Maybe
  a better example would be a one that converts Content MathML
  into presentation MathML.

* In §3.5, groups use inputs via parameter bindings.  Do we still
  consider that as "no inputs" ?

* In §3.6, there is an ed. note that says that step failures are a
  different class of errors.  In XSLT 2.0, these kinds of failures are
  dynamic errors.  Why wouldn't we do the same a limit the failures
  to two classes?  That would mean a try/catch could also catch
  failures related to input cardinality/etc.

* In §3.7, there is a note about generating static errors for steps no
   recognized by the pipeline processor.  There are two classes of
  "not recognized": one where there is no p:declare-step and one
   where the processor can't match the p:declare-step to an
   implementation.  Somewhere, not necessarily in §3.7, we need
   to discuss both.

* In §4.3, I'm not sure "quoted" is the right term for inline documents.
Maybe
  something with "verbatim" ?

* In §4.4, the XHTML namespace is ignored.  I'm not certain we should have
  any defaults here.

* In §5, many of the content models have a preferred order for p:input,
p:output,
  p:parameter, etc.  Why wouldn't we just have a model that allows them in
  any order:

  (p:input|p:output|p:parameter|...)*

 ?
* In §5.1, the ed note says document order.  We should just say "last step
  in document order...".  Or we define that as a term in our spec.

* In §5, all the inheritance of environments text is almost exactly the same
  in each section.  Can we define that as a single operation and note
  any exceptions?

* In §5.4, do we need the restriction that the xpath-context can't be a
sequence
  of documents ?

* Why don't we use xs:boolean for boolean flags instead of "yes" and "no"
  (e.g. the sequence attribute on p:input)?

* In §6.4, it says:
"
It is also a *static
error<http://www.w3.org/XML/XProc/docs/langspec.html#dt-static-error>
* if the step on which this declaration appears has exactly one output and
that output is marked as not being the default. In other words, if any step
or step has exactly one output, that output is always the default output."

  I think we should just say that if you say default="no" you get a static
error and if
  you don't specify the default attribute it assumes "yes" in this case.
That is, you
  only get a static error if you say default="no" and only have one output.

* In §6.6, what is the purpose of the *:NCName syntax ?**

* In §6.12, the anyElement production shouldn't be optional.  We should
  have exactly one element as a child.

* In §6.13, do we really want to exclude validation?  Even DTD validation?

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics