Re: exclusions

[James Clark <jjc@jclark.com>]

The <restriction> element in XML Schema is used for restricting both
simple types and complex types.  It's use for restricting simple types
depends on the facets defined in XML Schema Part 2.  The whole idea of
restricting a simple type depends on having a system of datatypes that
has a set of facets defined.  This kind of restriction is part of the
datatype system, and TREX already supports this.  By putting a global
attribute of trex:role="datatype" on an element, you can signal to TREX
that you have an element from another vocabulary that is being used to
describe a datatype.  JTREX supports the <restriction> element here.  So
you can say:

<xsd:restriction trex:role="datatype" base="xsd:positiveInteger">
  <xsd:maxInclusive value="365"/>
  <xsd:minInclusive value="10"/>
</xsd:restriction>

This works in the current release of JTREX.  This syntax is a bit
clunky.  It would be nice to be able to say instead:

  <data type="xsd:positiveInteger" xsd:maxInclusive="365"
xsd:minInclusive="10"/>

but I think it may be hard to make this work.

I don't see a whole lot of connection between this sort of restriction
and excludeElement.

With restriction of complex types you simply give a new content model,
and there's a requirement that anything allowed by the new content model
would also be allowed by the old content model.  This is kind of
pointless unless you have a notion of a named complex type hierarchy,
which XML Schema does and TREX does not.

Michael Fitzgerald wrote:
> 
> Do you intend for it to only exclude only elements, hence <excludeElement>?
> Do you think <restriction> to be the analogue of <excludeElement> from XML
> Schema? As you probably know, <restriction> allows you to restrict or
> exclude a wide variety of things, e.g. the upper limit of the value of an
> XSD datatype via <maxExclusive> or strings for enumerations or attributes
> or...If you intend broader use than elements, why not just call it
> <exclude>? Since TREX supports XSD datatypes, if we use a positiveInteger,
> do we have to stick with the range 1 to 126789?
> 
> Pot shot => What if you wanted to do something like:
> 
> <t:exclude name="xsd:positiveInteger" type="max">365</t:exclude>
> 
> <t:exclude name="xsd:positiveInteger" type="min">10</t:exclude>
> 
> where:
> 
> <t:element name="t:exclude">
> ...
>  <t:attribute name="type">
>   <t:choice>
>    <t:string>attribute</t:string>
>    <t:string>element</t:string>
>    <t:string>max</t:string>
>    <t:string>min</t:string>
>    <t:string>...</t:string>
>    ...
>   </t:choice>
>  </t:attribute>
> </t:element>
> 
> Or am I slouching toward complexity?
> 
> -Mike
> 
> > -----Original Message-----
> > From: James Clark [mailto:jjc@jclark.com]
> > Sent: Tuesday, March 13, 2001 8:43 PM
> > To: TREX Discussion List
> > Subject: exclusions
> >
> >
> > At the moment to model an exclusion in TREX, you have to use concur.
> > Here's an example from the XHTML DTD:
> >
> > <define name="a">
> >   <element name="a">
> >     <ref name="a.attlist"/>
> >     <concur>
> >       <ref name="Inline.model"/>
> >       <ref name="a.concur"/>
> >     </concur>
> >   </element>
> > </define>
> >
> > <define name="a.concur">
> >   <grammar>
> >     <start name="not.excluded">
> >       <zeroOrMore>
> >         <choice>
> >           <element>
> >           <not>
> >             <name>a</name>
> >           </not>
> >             <zeroOrMore>
> >               <attribute>
> >               <anyName/>
> >             </attribute>
> >             </zeroOrMore>
> >           <ref name="not.excluded"/>
> >           </element>
> >           <anyString/>
> >       </choice>
> >       </zeroOrMore>
> >     </start>
> >   </grammar>
> > </define>
> >
> > While this is kind of cool, it is not easy to write, nor is it obvious
> > to a reader what the intent is. It also suffers from all the
> > disadvantages that are entailed by use of concur (as I outlined in my
> > previous message).
> >
> > One alternative would be to have an element that supported exclusions
> > directly:
> >
> > <define name="a">
> >   <element name="a">
> >     <ref name="a.attlist"/>
> >     <excludeElement name="a">
> >       <ref name="Inline.model"/>
> >     </excludeElement>
> >   </element>
> > </define>
> >
> > Like the "element" and "attribute" elements, the "excludeElement"
> > element would have either a "name" attribute or a child element
> > specifying a name class.  The semantics of
> >
> > <excludeElement> nc p </excludePattern>
> >
> > would be that it matches any sequence that matches p and that does not
> > contain at any depth an element whose name matches nc.  This has a nice
> > simple semantics, is not hard to implement and can be "transformed out".
> >
> > <excludeElement> nc <choice> p1 p2 </choice> </excludeElement>
> > =>
> > <choice>
> >   <excludeElement> nc p1 </excludeElement>
> >   <excludeElement> nc p2 </excludeElement>
> > </choice>
> >
> > <excludeElement> nc1 <element> nc2 p </element> </excludeElement>
> > =>
> > <element> <difference> nc2 nc1 </difference> p </element>
> >
> > etc.
> >
> > Are exclusions important enough to be worth this?  My feeling is that
> > they are important enough for documents (eg footnotes don't nest) to
> > justify this.
> >
> > James
> >
> >