W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > September 2006

Re: Final draft for publication on 28 Sep 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 21 Sep 2006 10:23:43 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87irjhguxc.fsf@nwalsh.com>
/ Erik Bruchez <ebruchez@orbeon.com> was heard to say:
| 2.2 Inputs and Outputs
|
| "Although come kinds" -> "Although some kinds"

Fixed.

| 4.2.7 p:param Element
|
| "evaulated" -> "evaluated"

Fixed. (Actually, I think this just went away in some rewording, at
least, I can't find "evaulated" anywhere.)


| Besides the typos that I hope can be fixed, I don't think we should
| stop the press for our first public WD.
|
| A few comments about a few things that bothered me though:
|
| o The terminology "here document" is a little funny. Have we thought
|   about "in place document" or "inline document" instead?

I agree. It's common Unix shell parlance, but not really ideal. On the
other hand, I just proposed doing away with them altogether ;-)

| o In section "1 Introduction", we say that the input to a component
|   comes "from the web, from the pipeline document, from the inputs to
|   the pipeline itself, or from the outputs of other components in the
|   pipeline". When you read it this sounds like an exhaustive list, but
|   it is not since we can use URIs to feed inputs. For example the
|   input of a step can be file:/c:/foo.xml, which is none of the above.

I think of that as "from the web". I suppose we could say instead
"from a URI", but I thought from the web read better.

| o In section "4.1 Overview", we say that "Elements which represent
|   components all have unique names", but as we say in 4.2.1 and 4.2.5,
|   uniqueness depends on scope. So the wording in 4.1 is confusing.

I took out the word "unique" in 4.1 (I'm treating that as editorial).

| o In section "3.6 Try/Catch", I assume that we can have try/catch
|   within a catch (since the content of catch is a subpipeline), in
|   which case the wording "If the recovery subpipeline is evaluated and
|   a component within that subpipeline fails, the try fails." is not
|   clear enough. For example, you if a nested component fails but is
|   encapsulated within a nested try, then the corresponding nested
|   catch takes care of the failure.

That's the case I was trying to cover. If the recovery pipeline
contains another try catch, then it fails *if that component fails*.
But the inner try/catch may mask failurs inside it. Anyway, I'm sure
you're right that the wording can be improved. I'll take a stab at it
in the next draft.

                                        Be seeing you,
                                          norm

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

Received on Thursday, 21 September 2006 14:23:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:48 GMT