- From: Innovimax SARL <innovimax@gmail.com>
- Date: Sun, 25 Feb 2007 10:13:38 +0100
- To: "Norman Walsh" <Norman.Walsh@sun.com>
- Cc: public-xml-processing-model-wg@w3.org
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