[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Victory has been declared in the schema wars ...

• From: peter murray-rust <pm286@c...>
• To: "Rick Jelliffe" <rjelliffe@a...>
• Date: Sat, 02 Dec 2006 15:24:26 +0000

At 14:37 02/12/2006, Rick Jelliffe wrote:
>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.)

Rick - this looks great. Assuming it works out I shall start to 
convert as soon as practicable. You say "new "abstract patterns" " - 
can you elucidate a bit more when and where? I assume new to Schematron.

><snip/>



>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 starts to show the limitations of Schematron/XSLT. There are 
actually 3 stop codon sequences so the description is either verbose 
or nested or impossible. They are also (slightly) species and 
compartment-dependent. And for start codons you have to worry about context.

So I would like to be able to call a function like:
DNAPROG.isStopCodon(...)


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

But generally this seems to give much of the flexibility required. In 
which case CML may develop as:
(a) a set of content-agnostic elements with corresponding Java 
classes (exists already)
(b) a set of dataTypes which can be applied to either simple element 
content or attribute values (exists already)
(c) element-specific attributes based on these types
(d) generic attributes based on these types with specific Java 
classes and available, in principle, for any element
(e) Schematron patterns to describe what is allowed, what is 
encouraged, what is deprecated, etc.
(f) tools to generate element- and attribute- specific functionality 
from these patterns.

The elements and attributes will be defined in XSD because that what 
we have but we shall throw the content models away.

P.


Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road,  Cambridge CB2 1EW, UK
+44-1223-763069 

• Follow-Ups:
  • Re: Victory has been declared in the schema wars ...
    • From: "Rick Jelliffe" <rjelliffe@a...>

• References:
  • Re: Victory has been declared in the schema wars ...
    • From: peter murray-rust <pm286@c...>
  • Re: Victory has been declared in the schema wars ...
    • From: "Rick Jelliffe" <rjelliffe@a...>