Re: Editing in earnest

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