RE: [xml-dev] Victory has been declared in the schema wars ...

["Len Bullard" <cbullard@hiwaay.net>]

Cross-posting because this has interesting applications for real time 3D
modeling.   Yo, Brutzman! The NPS folks could look into this.

This could be applied to X3D where components for standard 3D models could
be created.  X3D is a geometry/behavior/material application, meaning
semantically at the level of the language, it is vertices, scripts and event
data types.  That makes it deuce-hard for figuring out if the model received
validates under any higher level semantic constraints.

len

From: Rick Jelliffe [mailto:rjelliffe@allette.com.au] 

peter murray-rust said:

> A major use of the schema is to autogenerate code and so I would like
> functionality like "this element may | must | must_not contain these
> children" and similarly for parents. This allows my to generate code
> that may be  valuable to the developers.

This is where the new "abstract patterns" come in. To a good extent, they
let you make up the particular abstractions that will be most convenient for
you and your application. (The definitions of RequiredChild etc below are
trivial and not shown, to minimize distractions.)

For example,
  <pattern is-a="RequiredChild">
     <param name="element" value=" AAA "/>
     <param name="child"  value=" XXX "/>
  </pattern>

  <pattern is-a="OptionalChild">
     <param name="element" value=" AAA "/>
     <param name="child"  value=" YYY "/>
  </pattern>

  <pattern is-a="ProhibitedChild">
     <param name="element" value=" AAA "/>
     <param name="child"  value=" ZZZ "/>
  </pattern>

  <pattern is-a="ClosedContent">
     <param name="element" value=" AAA "/>
     <param name="content"  value=" XXX or YYY "/>
  </pattern>


Abstract patterns provide compile-time named parameterization of Schematron
patterns.  Variables (let) provide run-time parameterization of XPaths.

Here is another example. Imagine our data consists of an element
<DNASequence> that can contain a list of <U/>, <A/>, <G/>, <T/> or <U/>
elements. We want to test whether this sequence contains a stop codon: the
abstract pattern would be implemented using report...this is Schematron
used for reporting not for validation.

  <pattern is-a="DNAStopCodon" >
     <param name="CodonName" value="'UAA'"/>
     <param name="DNAString" value=" DNASequence " />
     <param name="CodonPath"
            value="U[following-sibling::A[following-sibling::A]]"/>
  </pattern>

  <pattern is-a="DNAStopCodon" >
     <param name="CodonName" value="'UGA'"/>
     <param name="DNAString" value=" DNASequence " />
     <param name="CodonPath"
            value="U[following-sibling::A[following-sibling::A]]"/>
  </pattern>


  <pattern is-a="DNAStopCodon" >
     <param name="CodonName" value="'UAG'"/>
     <param name="DNAString" value=" DNASequence " />
     <param name="CodonPath"
            value="U[following-sibling::A[following-sibling::A]]"/>
  </pattern>

This, I think, gets us back to spirit of XML: you need a structure? then
just specify it in the most direct way possible and hide or defer
specifics
of implementation to a separate layer or stage. XML gives you the freedom
to do this for documents, abstract patterns gives you the ability to do
it for classes of documents.

The definition for DNAStopCodon could be something like (untested but you
get the idea:

  <pattern name="DNAStopCodon" abstract="true">
     <rule context=" $DNAString ">
        <report test=" $CodonPath ">
          <value-of select="CodonName" /> found at position
          <value-of select=" position() ".
        </report>
     </rule>
  </pattern>