RE: conjunction types

Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com] wrote:

Would you limit this to cases in which the lexical spaces of the 
"conjoined" types are disjoint?  I think you have to.
---------------

I don't think that there is a problem with overlapping types in validation.  

It only becomes an issue if you are trying to use to a <conform> facet to imply a return type (i.e. variant type) for an advanced accessor method or a storage type for some mapping to a database.
Both of those uses appear to be outside the scope of XML Schema and could be deferred to later standards.

However, some sort of precedence would be sufficient.  I'd suggest the first <conform> facet that was required to be executed and was satisfied that was not within a <nor> facet and where any
containing <and> facet was satisified. 

Here is a type that overlaps:

<simpleType name="ints-plus-some-doubles" base="double">
	<or>
		<and>
			<minInclusive value="-1"/>
			<maxInclusive value="1"/>
		</and>
		<conform type="integer"/>
	</or>
</simple>

All values must be in the value and lexical space of the base type, double.  In additional values, must either be in the range -1 >= x >= 1 or integers.

Having a 'getTypedValue' just return the base type (double) would be acceptible.  

However, if you required or allowed 'getTypedValue' to be smarter, then:

0,1 and -1 would be returned as doubles since they satisfy the first clause and the conform facet does not need to be evaluated (switching the order of the <and> and <conform> would make them
integers). 

All other values between -1 and 1 would also be doubles by the same logic.

All integers other than -1,0 and 1 would be returned as integers.

Anything else would not validate.

If you really wanted to force clauses to be disjoint (which I don't believe is necessary), then you should rename the <or> facet to <xor>.

Note: In a previous message I had mentioned some qualms about how list types were parsed suggesting that they should be based on completion of the type production before looking for the separating
spaces.  Though possible, that suggestion would be complex with conjunction types.  This list parsing methodology described in the 25 Feb draft would work well with conjunction types.

Received on Wednesday, 8 March 2000 11:54:09 UTC