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