Re: Editing in earnest

Norm,

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
==typos==
(still around since last draft)
s/inherted/inherited/
s/XIinclude/XInclude/
s/evaulated/evaluated/
s/subpiplines/subpipelines/


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

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

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


Regards,

Mohamed


[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
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Received on Sunday, 25 February 2007 09:13:52 UTC