Re: Review of Spec

/ Alex Milowski <alex@milowski.org> was heard to say:
| * 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?

I hope so :-)

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

Maybe.

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

I hope my earlier explanation was sufficient.

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

I took a stab at improving that.

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

Fixed.

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

I do.

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

That still needs discussion.

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

I tried to fix that.

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

I still like quoted.

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

We should discuss that.

| * 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|...)*
|
| ?

Because unnecessary variation is bad.

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

I tried.

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

Ok, I gave it a whirl.

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

I don't think XPath 1.0 defines the semantics of evaluation over 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)?

I hope that's been discussed enough already.

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

Uhm, yeah :-)

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

We should fix that.

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

I do, as I said.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.