As it is currently formulated, the interpretation of the lexicalRepresentation element is dependent on the ultimate ancestor type of the datatype, though only an interpretation for datatypes derived from "string" is formulated. I think it would be simplify things to replace the current functionality of lexicalRepresentation element with a <regex> element that could be applied to the lexical space regardless of the base class. When a clear definition of the lexicalRepresention is formulated, then it could be reintroduced in addition to the <regex> element. I think part of the problems is that you are only allowing a mechanism to inherit both the value space and the lexical space from the base type. What might be be a way to address the problem is to allow a derived class to specify transforms that would map its lexical space into that of its base class. For example, if I wanted to declare a boolean datatype that used 0 and 1 instead of "true" and "false", it could be something like <datatype name="intBoolean"> <!-- I inherit the boolean data space --> <basetype name="boolean"/> <regex>[01]</regex> <!-- match and replace would be regular expression translation, first matching transform would take precedence --> <transform match="0" replace="true"/> <transform match="1" replace="false"/> </datatype>Received on Tuesday, 28 September 1999 11:57:30 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 October 2007 06:13:15 GMT