Re: Datatypes

[Murata Makoto <mura034@attglobal.net>]

>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