[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Name classes
> I have a question about the design of name classes. > What is the design criteria behind the current spec? > > name-class ::= <t:name ns="namespaceURI"> NCName </t:name> > | <t:anyName/> > | <t:nsName ns="namespaceURI"/> > | <t:choice> name-class name-class </t:choice> > | <t:difference> name-class name-class </t:difference> I considered amongst other things - wildcards in XPath - what XML Schema can express - what the XML Query Algebra can express - what is needed to write a TREX pattern for XSLT - what is needed to write a TREX pattern for XHTML - what is needed to support RELAX semantics > There are other possibilities. For example, simpler designs > are: > > 1) URI+localName pairs only > 2) URI+localName pairs and <anyName> only > 3) URI+localName pairs, <anyName>, and > <nsName namespaces="namespaceURI1 namespaceURI2 namespaceURI3"/> only I found that any solution that didn't use a nested structure with a set of primitives and a set of operations to combine them became messy fast. In particular, I believe it is necessary to support - any namespace (including null) other than a particular namespace - any non-null namespace other a particular namespace - any non-null namespace - just the null namespace - a particular namespace - any namespace at all Also I wanted to be able to support lax validation (eg the RELAX 1 semantics for attributes): <element name="foo"> <optional> <attribute name="bar"><data type="xsd:int"/></attribute> </optional> <optional> <attribute name="baz"><data type="xsd:int"/></attribute> </optional> <zeroOrMore> <attribute> <not> <choice> <name>bar</name> <name>baz</name> </choice> </not> </attribute> </zeroOrMore> </element> eg you can have any attribute but any bar or baz attribute must be of type xsd:int. > On the other hand, we can introduce more powerful primitives. For > example: > > 4) (URI, Unicode regular expression) pairs > 5) (URI, Unicode regular expression) pairs and <nsName ns="namespaceURI"/> > 6) <intersection> on top of 3) > 7) boolean operations on top of 4) or 5) > > Certainly, Unicode regular expressions are useful. For examplem, I > might want to allow all HIRAGARA-KATAKANA-KANJI attributes and they > specify that their contents are ASCII-HIRAGANA-KATAKANA-KANJI-PUCNATIONMARKS. That seems fairly clearly on the wrong side of the 80/20 line. It's not needed for any of the things I considered. Note that the current design is almost identical in functionality to namesets in the current (internal) XML Schema Formal Description draft. I think similarities with XSFD are a good thing. James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC