[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Datatypes
>1. For the key and keyRef attributes on data, we need a definition of >datatype identity. We can resolve a datatype into a primitive datatype >name, a set of parameters and a set of values. One possibility is to >say that two datatypes are the same if all these three things are the >same. Should datatype parameters be considered as typed for the >purposes of determining identity? James Clark wrote: > > We don't exactly need datatype equality. All we need is to check that the > two datatypes use the same equivalence relation for comparing strings (let's > call this "compatible"). Thus the enumeration of possible values is > irrelevant. I think the datatypes should be treated as compatible if the > base types are the same, and the values of all the parameters are the same > (compared type-sensitively?). This is not harder to implement. Just sort > of the list of parameters by name and them compare the values. If we can assume that parameters never change the equivalence relation, we can always compare the base type name. If this assumption cannot be accepted, I do not see any good sotlutions. I think that type-sensitive comparison is too much. For the validator to know that maxInclusive is of the type "int", it has to know all parameters of the built-in datatypes of XML Schema Part 2. If we use aother datatype library, the validator has to know all parameters of that library too. >2. Can setParams override parameters that the base datatype specifies? To finish our first draft, I would propose not to allow types derived from user-defined types. >3. Does datatype have a combine attribute? If so, what values can it >take? At least it should allow replace. I don't like replace (Issue 20). http://lists.oasis-open.org/archives/trex/200105/msg00120.html#orderSignificance On the other hand, I think that it should be possible to add values to a list of allowed values (specifed by <enum>). >4. Should enum be called enumeration instead? My two cents: yes. >5.Should ns be renamed to targetNamespace instead of defaultNamespace? For the design of RELAX Namespace (on top of our lang), I am assuming a convention that a pattern file (or a module) has one target namespace and possibly multiple auxiliary namespaces. Since such auxiliary namespaces are different from target namespaces, I very much prefer "defaultNamespace". >6. Can you use setParams to derive from a datatype defined by enum? Again, to finish our first draft, I would propose not to allow types derived from user-defined types. >7. Should any other datatypes be built into TREX other than string >and normalizedString? A datatype for 0 or 1 rather than true, false, 0, 1? >8. How should whitespace-separated lists of datatypes be supported, >if at all? As a minimalist, I would propose <list itemType='qname'/>. By not using <oneOrMore>, we do not further complicate "restriction on use of string/data in pattern" (issue 18). http://lists.oasis-open.org/archives/trex/200105/msg00120.html#restrictStringUse I also think that patterns for hedges and datatypes for whitespace-separated lists are different beasts. Cheers, Makoto
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC