RE: exclusions

[Michael Fitzgerald <mike@wyeast.net>]

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