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: Mon, 26 Feb 2007 16:05:51 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <87bqjgpr2o.fsf@nwalsh.com>
/ Innovimax SARL <innovimax@gmail.com> was heard to say:
| == missing try/catch in the RNG ==
| I dunno why it's still missing...


| == copy/paste ==
| p:viewport-source description contain p:iteration-source

| "The declared outputs of the p:group are the result of the [[group]."
| == in Example 5 ==
| <p:pipeline-library>
|  <p:declare-component> name="extension-component">…</p:declare-componenttype>
|  <p:pipeline name="xinclude-and-validate">…</p:pipeline>
|  <p:pipeline name="validate-and-transform">…</p:pipeline>
|  …
| </p:pipeline>
| should be
| <p:pipeline-library>
|  <p:declare-component(-type)?
| name="extension-component">…</p:declare-component-(type)?>
|  <p:pipeline name="xinclude-and-validate">…</p:pipeline>
|  <p:pipeline name="validate-and-transform">…</p:pipeline>
|  …
| </p:pipeline>

Fixed, I think.

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

| ==TBD==
| *define the ignore-prefixes attribute

Fixed. At least partially.

| == 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".

| ==Editorial Notes==
| << It is a dynamic error if a non-XML resource is produced on a
| component output or arrives on a component input.
| Editorial Note
| What about the cases where it's impractical to test for this error? >>
| I have an XSLT component that outputs HTML (not XHTML). By the first
| sentence, I even cannot use p:store/p:save because it need to be
| arrives on a component input !!!
| Does it mean that we must use output="xml" and then "unwrap" is
| necessary on a particular component ?

Yes. We probably want the p:store/p:save component to have parameters
like the xsl:output method='html' element.

| I fear that p:declare-component will need far more than a little
| section to be defined


| <<In the context of try/catch, "errors" refers to component failure
| which is not the same as a static or dynamic error in the pipeline
| itself. (Though perhaps it will be possible to recover from some
| dynamic errors.) The notion of component failure as a distinct class
| of error needs to be described.>>
| That's not enough in my perspective. As I already point this out, for
| validation purpose we need to catch dynamic errors as well as
| component failure. See [3] in Validate section
| The problem for static error could remain open for which I be more
| confortable with a "xsl:use-when"-like construct

Yes, try/catch is poorly specified today.

                                        Be seeing you,

Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.

Received on Monday, 26 February 2007 21:06:40 UTC

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