Julia Flanders wrote:
> Option B, though, does seem to be the kind of thing we often encourage
> people to do when we talk about customization. Isn't the beauty of ODD
> that if the TEI's choice in the matter doesn't meet your needs (e.g.
> choosing an overly fussy datatype for something as routine as
> measuring time), you can make the necessary adjustment in your TEI
Sort of. I am all in favour of limiting an existing datatype; so if Lou
wanted to limit the BNC
to durations of less than 3 minutes but more than 10 seconds, say, that
would be great.
But changing the basic meaning of the datatype from a time
representation in a standard
format to a simple number with assumed semantics seems bad to me. I
can't merge Lou's
material with mine for an analysis, for example.
OTOH, if Lou adopted position c) (@approxDur), he could map that to
using the <equiv> element, which would make it easier for to use his stuff.
> I don't see this as a sacrifice of conformance at all. I agree, option
> A might be the easiest thing in this particular case, but I'm curious
> about the general point here.
> Are you saying you'd define "conformance" as meaning "using a strict
> subset"? That's rather harsh, I think.
In the TEI Council at present there is a discussion of conformance in
which I attempted to define
different conformance types (I called them levels, but that has
connotations....). I won't rehearse
the arguments here, just to note that in my mind "conformance" means
stating your position on
a spectrum of possibilities. I don't want to limit the meaning of
"conformance" to just "strict subset".
Lou remarked to me privately that the BNC does not use the TEI namespace
for its elements,
which already puts it some way beyond the pale in my mind. But my pale
surrounds an area
close to the house, others may encompas greater areas of woodland and water.
This is a fun topic :-}
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
OSS Watch: JISC Open Source Advisory Service