On 31/12/12 09:34, Sebastian Rahtz wrote:
> The choice of an XML name was deliberate. The values are not supposed to be literal, but an arbitrary token, so you don't _need_ numbers. I agree, it can be annoying but is not a deal breaker. It was a convenience to use an existing data type.
> If we changed data.name to also allow 0-9, I suspect the world would continue to turn on its axis:-)
We do however distinguish data.name and data.enumerated : values
expressed directly as data.name are always likely to be XML names (e.g.
element names) and so it would certainly cause some discombobulation to
change that definition.
Arguably less defensible is the current equivalence between
data.enumerated and data.name -- some of those attributes which are
currently data.enumerated clearly could be data.name, since their values
come from a fixed valList, the values of which are expressed using the
@ident attribute, whose value is ... data.name. Others however are not
(stricly speaking) enumerated at all (i.e. don't come from a closed
list), though that taking that option is often considered good practice
in a specific project. And since, if you do make them a closed list, you
will need ipso facto to make them data.name, it's probably less work to
make them all data.name in the first place. I say nothing of those
@type values which are not inherited from att.typed, which are different
again, of course.
Mulling this over makes me realise that we have two mechanisms --
attribute class membership; and TEI-defined datatypes -- which overlap
significantly in their function. Maybe we might reconsider that.