RE: Updated language draft: 12 Sep 2006

All editorial; I leave it to the editor to decide what
should be addressed before FPWD.

fwiw, when I click on the XML link in IE, I'm shown the
XML in tree form--there appears to be no SS PI, so it
doesn't attempt to render as HTML.


The Abstract reads more like a status paragraph.  Move
this to the Status, and write a real Abstract for what
this document is supposed to be (eventually).


I see <rfc2119>may</rfc2119> and just "may".  This will
become a mess.  Though it probably doesn't have to happen
before FPWD, you might want to save yourself a headache
later and either (1) never use "may" when it isn't 2119,
(2) mark non-2119 mays (and shoulds and such) specially
so we know it was really not meant to be a 2119, (3) be
very careful that you mark 2119's not not others.  In
particular, "Outputs may also be ignored." seems like
a 2119 to me (but it isn't so marked).


 The pipeline itself has two inputs, "document" and "schema". 
 How these inputs are connected to XML documents is

Doesn't parse for me.  If one of the inputs is "document",
then the statement says "How 'document' is connected to
XML documents is implementation-defined."  I don't understand.

Besides, I thought the whole idea of the processing model
was to define how to process documents, so saying it's
implementation-defined doesn't sound right.  I'm sure
I'm misunderstanding something, but then perhaps other
people will too.


In Figure 2, I suspect the last component should be
"transform" rather than "validate".


I happen to know what "an acyclic, directed graph" is;
will the average reader, or should be have an "english"
translation of that?


 [Definition: A step which contains other steps is called
 a step containers.]

s/a step containers/a step container/


 [Definition: Any set of components, instantiated from one
 or more steps or a set of contained steps forms a subpipeline.] 

Unclosed subjunction clause.  Add a comma before "forms" or
delete the existing comma.


 (All components have a standard output port for reporting
 errors that does not have to be, and cannot be, declared.)

I suggest instead:
 (All components have an implicit standard output port for
 reporting errors that <rfc2199>must not</rfc2119> be declared.)


 [Definition: The instantiation of a component matches ....

Both for clarity and to match the style of other such
constructs later in this document, I suggest replacing
the commas in this long definition with semi-colons.


 Each XML document (or document in a sequence) must be a
 well formed [ XML 1.0 ] or [ XML 1.1 ] document. The inputs
 and outputs may be implemented as sequences of characters,
 events, or object models, or any other representation the
 implementation chooses.

I'm not sure you can say something is an XML document (and
point to the XML spec) and then say it could be object models.
The XML spec defines documents in terms of characters, not
objects.  I think we either need to point to the Infoset,
or we need some weasel words in here to make this work.


 An implementation may make it possible for a component
 to produce non-XML output, for example, writing a PDF
 document, but those results cannot flow through the pipeline.

I suggest (punctuation change only):

 An implementation may make it possible for a component
 to produce non-XML output--for example, writing a PDF
 document--but those results cannot flow through the pipeline.


 Similarly, one can imagine a component that takes no inputs,
 reads a non-XML file from a URI, and produces an XML output.
 But the non-XML file cannot be an input to the component or pipeline.

Most people would think if the component reads the non-XML file,
it sounds a lot like that file is an input to that component.

I assume you mean "input to the component" in the strict
XML Processing Model sense, but then you have to define
"input to the component" and make this reference a link
to that definition, or else this statement looks inherently


 [Definition: after is the converse of before.]

Good try, but spell it out.


 It is static error if a component is either before or after itself.

s/It is static error/It is a static error/


 Each subpipeline is effectively guarded by an XPath expression....
 The last subpipeline may be designated the default subpipeline;
 it will be selected if no preceding subpipeline was selected.

Needs wording help.

What do you mean by "effectively"--either it is or isn't.

Just what do you mean by "may be designated"--how?

Is the default subpipeline guarded by an XPath expression?
If so, that's weird; if not, then your first sentence above
is false.

[***This may all be covered in "4.2.11 p:choose/p:when/p:otherwise 
Elements", but I think the wording in 3.4 Choose should be improved.]


Re (in Try/Catch):
 However, if any errors occur, ...

What are errors?  We define static errors and dynamic errors,
we don't define errors.  Does the catch subpipeline get executed
in the case of static errors in the try component?  I suspect not,
but then you need to change "errors" to "dynamic errors" or something
in this phrase.


Re (in 4.1.1 Associating Documents with Ports):
 A document must be specified in exactly one of these ways.

Is that a 2119 "must"?

What happens if, say, all of the href, source, and step
attributes are assigned?  I assume this is a static error,
but we must say so.

***Actually, I later see this down in 4.2.6 p.input Element,
but I think it should be up here too.


 The scope of a port name is the component on which it is
 defined. The names of all input and output ports on any
 component must be unique.

Do we really mean:
 The names of all input and output ports within any given 
 scope must be unique.

Why define scope if we aren't going to use it?


Re 4.1.3 Syntactic Shortcuts example:

Should the "ex" namespace prefix be declared?


Re 4.2.13 p:try/p:catch Elements:
 However, if any component in that group signals an error...

Same comment as before.  I think we want to say "dynamic
error" here, but I'm not positive.

Similar issue with the word "error" in the next several
paragraphs too.


Re in 5.2 Dynamic Errors:



> -----Original Message-----
> From: 
> [] On 
> Behalf Of Norman Walsh
> Sent: Tuesday, 2006 September 12 12:37
> To:
> Subject: Updated language draft: 12 Sep 2006
> Available at:
> I believe I've done the things I said I'd do, plus I've tried to
> cleanup the language a little bit. I'm not sure how successfully.
> As before, I encourage you to review this with an eye most keenly
> towards things that you feel need to be fixed before it becomes a
> public working draft.
>                                         Be seeing you,
>                                           norm
> -- 
> Norman Walsh
> XML Standards Architect
> Sun Microsystems, Inc.

Received on Tuesday, 12 September 2006 18:53:56 UTC