lexicalRepresentation element

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 UTC