Re: XML Processing Model DSDL Use Case

[[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
ambitious.

| 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