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

Re: Editing in earnest

From: Innovimax SARL <innovimax@gmail.com>
Date: Sun, 25 Feb 2007 10:13:38 +0100
Message-ID: <546c6c1c0702250113o460dcf6cq5cc99cb700ef5d00@mail.gmail.com>
To: "Norman Walsh" <Norman.Walsh@sun.com>
Cc: public-xml-processing-model-wg@w3.org


On the fly remarks

A lot of old remarks still holds see [1] and [2]

== missing try/catch in the RNG ==
I dunno why it's still missing...
== copy/paste ==
p:viewport-source description contain p:iteration-source
(still around since last draft)

"The declared outputs of the p:group are the result of the [[group]."
== in Example 5 ==
  <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>

should be

  <p:pipeline name="xinclude-and-validate"></p:pipeline>
  <p:pipeline name="validate-and-transform"></p:pipeline>

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

*define the ignore-prefixes attribute

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

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


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



[1] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0053.html
[2] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0051.html
[3] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0055.html

On 2/23/07, Norman Walsh <Norman.Walsh@sun.com> wrote:
> I've begun editing the language spec in earnest, attempting to
> integrate the things we've decided, planning to integrate the
> editorial comments that I've been sent, and making up what's necessary
> as I go along.
> If you want to follow along, I'm checking things into
>   http://www.w3.org/XML/XProc/docs/langspec.html
> as I go. Probably about daily. But that doesn't mean there's any real
> editorial stability from one day to the next.
> Today's draft has been reorganized a little, contains sections for all
> the p:* elements we've discussed (including p:viewport-source which I
> had to invent), attempts to describe things in terms of atomic and
> compound components since it didn't seem to make much sense to
> distinguish between steps and language constructs now that we don't
> have a p:step, and tries to resolve some issues about the environment
> and default inputs in a practical way.
> I'm still not sure I like having information split between Section 3
> and Section 4.2 but last time I tried to change that, I got more nays
> than yeahs.
> Comments welcome, but only if you feel like reading the work in
> progress.
> Comments on things marked "Editorial notes" might be most useful.
>                                         Be seeing you,
>                                           norm
> --
> Norman Walsh
> XML Standards Architect
> Sun Microsystems, Inc.

Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Sunday, 25 February 2007 09:13:52 UTC

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