- 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... Fixed. | == copy/paste == | p:viewport-source description contain p:iteration-source Fixed. | | "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 Indeed. | <<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, norm -- Norman Walsh XML Standards Architect Sun Microsystems, Inc.
Received on Monday, 26 February 2007 21:06:40 UTC