- From: Innovimax SARL <innovimax@gmail.com>
- Date: Tue, 27 Feb 2007 00:43:57 +0100
- To: "Norman Walsh" <Norman.Walsh@sun.com>
- Cc: public-xml-processing-model-wg@w3.org
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>> > > | ==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". 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 > > | ==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. But does it truly mean in that perspective that *only* output="xml" will be allowed ? > > | 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. I think it will be good to start a thread around errors and try/catch Mohamed -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 8 72 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Received on Monday, 26 February 2007 23:44:05 UTC