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

Re: XML Processing Model DSDL Use Case

From: Norman Walsh <ndw@nwalsh.com>
Date: Fri, 17 Mar 2006 21:32:46 +0000
To: "Martin Bryan" <martin.bryan@csw.co.uk>
Cc: <dsdl-discuss@dsdl.org>, public-xml-processing-model-wg@w3.org
Message-ID: <873bhgbvvk.fsf@nwalsh.com>
>[[PGP Signed Part:Norman Walsh <ndw@nwalsh.com>]]
>[Adding public-xml-processing-model-wg@w3.org to CC:]
>/ "Martin Bryan" <martin.bryan@csw.co.uk> was heard to say:
>| Norm
>| Many thanks for taking on board the DSDL requirements as an acknowledged
>| use case for the XML Processing Model.
>| You asked the following perceptive questions:
>|>In particular, we're not sure how step 7 fits its results into the
>| right places and how the compound document is reassembled from all the
>| split and now transformed components.
>| These are the two key issues that we have been unable to resolve within
>| the DSDL committee so far. Step 7 seems the easiest to identify a
>| solution for. Where a specific namespace is invoked we would use NVDL
>| (ISO 19757-4) to separate it out for validation on its own, against the
>| schema for that namespace, ie MathML. At this point it is proposed that
>| the validation result would be sent for transformation and the result of
>| the transformation would be put back into the document tree at the point
>| the fragment was extracted for validation.
>I think I understand that bit. If we had some sort of "peephole"
>component that could apply one or more steps to a portion of a
>document while the rest of the document "flowed around" the component,
>then I could imagine something like this:
>  <p:peephole select="selectMathML">
>    <p:step name="validate"/>
>    <p:step name="transform"/>
>  </p:peephole>
>| Now this has an assumption in
>| it that when you hit a new namespace you start a different validation
>| process. Obviously this is not always going to be the case, so the
>| processing model needs some way of listing those namespaces for which
>| separate validation is required. 
>I'm not sure (speaking personally) that I think the DSDL use case is
>one that we could expect to solve using only the "core component" of
>the pipeline language. I think the initial box in your picture "Use
>NVDL to separate namespace streams" may have to be a custom component
>of some sort. And that's the component that can stitch things back
>together again.
>I guess the part I still find confusing is the way the arrow that
>comes out of "Transform MathML to SVG" connects to the arrow that
>comes out of "Check SVG subset with Schematron". I think I can imagine
>how arrows and boxes are hooked together, but what's the significance
>of the "arrow-to-arrow" join?
>Another problem I have with your diagram is the box labelled "Validate
>character sets" on the right hand side. I had thought we were in an
>XML-to-XML world and therefore character sets were no longer relevant.
>Am I missing something there too?
>| Having, in our example scenario named HTML, SVG and MathML as the tree
>| seperately validatable namespaces we would expect an occurrence of an
>| element in that namespace to invoke a separate validation/transformation
>| process and to record where in the originating stream that fragment had
>| been extracted. One thought was that you could perhaps replace the
>| extracted fragment with an Xinclude statement that would be activated
>| during the reconstruction phase. We have an acknowledged problem with
>| NVDL in that streams are not labelled adequately for this purpose. We
>| know this has to be fixed before we can manange validation fully. We
>| were hoping you would come up with the best solution :-)
>Heh. I think I can see how to do individual "peephole" steps, but the
>idea of building a dynamic set of peepholes (nested within each other
>in effect, I think) of unbounded cardinality strikes me as a bit
>| You also asked: Do you perhaps have some simpler use cases that we could
>| build upon?
>| I feel that any simpler, two-way split, is too simplistic to test
>| properly test any proposed language. We deliberately chose a three-way
>| split to show that there may need to be multiple nested processes. Three
>| streams is the minimum you can use to demonstrate this adequately.
>You may find it difficult to convince the XProc WG that this use case
>should reasonably be addressed by the V1.0 processing language using
>only core components. :-)
>| Martin Bryan
>| Convenor. ISO/IEC JTC1/SC34/WG1
>| -----Original Message-----
>| From: Norman Walsh [mailto:ndw@nwalsh.com] 
>| Sent: 16 March 2006 19:49
>| To: Martin Bryan
>| Subject: XML Processing Model DSDL Use Case
>| Hi Martin,
>| The XProc WG has incorporated your use case into its requirements and
>| use cases document[1], but we're a little confused about how it's
>| supposed to work.
>| Although it claims to be a validation management use case, it
>| incorporates transformation as well and it isn't clear how the bits are
>| supposed to fit together.
>| In particular, we're not sure how step 7 fits its results into the right
>| places and how the compound document is reassembled from all the split
>| and now transformed components.
>| Can you shed any light on this use case? Do you perhaps have some
>| simpler use cases that we could build upon?
>|                                         Be seeing you,
>|                                           norm
>| [1]
>| http://www.w3.org/XML/XProc/docs/langreq.html#use-case-dsdl-validation
>| --
>| Norman Walsh <ndw@nwalsh.com> | People often say that this or that
>| http://nwalsh.com/            | person has not yet found himself. But
>|                               | the self is not something one finds, it
>|                               | is something one creates.--Thomas Szasz
>                                        Be seeing you,
>                                          norm
>Norman Walsh <ndw@nwalsh.com> | The stone fell on the pitcher? Woe to
>http://nwalsh.com/            | the pitcher. The pitcher fell on the
>                              | stone? Woe to the pitcher.--Rabbinic
>                              | Saying
>[[End of PGP Signed Part]]
Received on Saturday, 18 March 2006 10:40:41 UTC

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