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

Re: Editing in earnest

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Tue, 27 Feb 2007 08:52:49 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <87d53v672m.fsf@nwalsh.com>
/ Innovimax SARL <innovimax@gmail.com> was heard to say:
| Norm,
| On 2/26/07, Norman Walsh <Norman.Walsh@sun.com> wrote:
|> / Innovimax SARL <innovimax@gmail.com> was heard to say:
|> | == p:inline : why allowing containing sequence ? ==
|> | in my conception, p:inline should contain 1 and only one document
|> | If you need to reach 2 or more, you need to wrap each around a p:inline
|> | The problem to reach 0 has not yet been solved, AFAIK
|> The ? isn't a sequence, it's a choice. So an empty p:input solves the
|> 0 problem. Putting more than one element is an error.
| The problem is that *it is defined as a sequence* !
| <<A p:inline provides a sequence of documents inline>>

Ah. Fixed.

|> | == State of status quo ?==
|> | If we didn't reach consensus on changing "<p:input port=" and
|> | "<p:output port=" to "<p:input name=" and "<p:output name=", i propose
|> | to vote on this issue asap
|> I don't recall discussing that. Not to say that we didn't...
|> Personally, I'm in favor of retaining the name "port".
| I think that now that we have the <p:pipe clearly define, we could
| take a look to have @name as *everywhere* else in the spec

Sure, that makes sense.

I favor retaining @port on p:input/p:output because I think it
makes p:pipe clearer:

  <p:pipe step="someName" port="somePortName"/>

Saying that somePortName is the @port on a p:output seems clearer
to me than saying that somePortName is the @name on a p:output.

I'm not so sure about @step on p:pipe now, but ...

|> Yes. We probably want the p:store/p:save component to have parameters
|> like the xsl:output method='html' element.
| But does it truly mean in that perspective that *only* output="xml"
| will be allowed ?

That's pretty clear in the spec. From 2.2:

   Although some components can read and write non-XML resources, what
   flows between components as inputs and outputs are exclusively XML
   documents or sequences of XML documents.

There have bee a couple of proposals floated for how to wrap non-XML
stuff in XML so that it can flow through the pipe, but I don't think
we have consensus to do that yet.

|> Yes, try/catch is poorly specified today.
| I think it will be good to start a thread around errors and try/catch


                                        Be seeing you,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Tuesday, 27 February 2007 13:54:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:41 UTC