Re: Review of Spec

/ Alex Milowski <alex@milowski.org> was heard to say:
| * In §2.2, I don't understand the editorial note.

Suppose you have a step which simply returns the namespace of the root
element of its input document:

  <rootns>http://docbook.org/ns/docbook</rootns>

Suppose further that you pass it a 3Gb DocBook document. Is the
implementation required to consume the entire document before it
returns the answer.

Suppose it reads the document in a streaming fashion and, as soon as
it's seen the root element, outputs its result and closes the input
stream. What if there was a WF error after 2.5Gb of input and the
component never saw it?

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

But they aren't necessarily passed to the step. Consider:

  <p:group>
    <p:param name='foo' value="testing"/>

    <p:xslt/>
  </p:group>

The stylesheet run by that XSLT step does not get a binding for the
'foo' parameter.

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

We have a component that does that? :-)

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

They aren't p: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.

Well. Maybe we could do that. I've been thinking of dynamic errors
(your p:choose didn't have a matching p:when or a p:otherwise) as
unrecoverable.

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

Indeed.

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

I like quoted better, but I'm not going to lie down in the road over it.

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

I can see both sides.

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

Why allow all that unnecessary variation?

| * 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 can't find that ednote.

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

Maybe. But I thought there was enough variation and the text was short
enough that it was better this way.

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

I thought we decided that.

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

Because we don't require schema support to interpret xproc documents.

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

Isn't that what it says?

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

Logical completeness?

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

You don't want to be able to identify an empty sequence of documents?

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

Either all implementations must do it the same way or we must provide
a flag to let the author choose which they want.

Since we have a load component that can do DTD validation, I thought
it was simpler to simply say that p:document doesn't validate.

                                        Be seeing you,
                                          norm

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