[tei-council] datatype of @n in att.global

James Cummings James.Cummings at computing-services.oxford.ac.uk
Fri Jun 29 05:14:38 EDT 2007


Sebastian Rahtz wrote:
> I have been caught out a lot of times today by the fact that
> the value of  "n" is constrained so that it cannot contain spaces.
> Given that it "gives a number (or other label) for an element, which is
> not necessarily unique within the document", I think
> this is unreasonable. One can easily imagine
> labels such as "45 (3)" , "Documents and Settings/foo.xml"
> or "No. 6" (as in "come in No. 6, your time is up".
> 
> I humbly petition the court that space be allowed
> in att.global/@n


In playing devil's advocate, I'd like to call as witness, one Sebastian
P.Q. Rahtz.  Mr Rahtz, did you not around 2006-09-05T08:33 in a discussion
of renaming filenames, respond to Lou Burnard's suggestion that we could
"supply them as values for the @n attribute on <div1>s" with the sarcastic
quip that "We wouldn't want to abuse @n with free text now would we...."?

The labels you indicate above are compound ones, that could easily be given
in some form which does not require spaces.  (And file paths really
shouldn't be used as labels.)  The description refers to 'a number' (or
label), that is a *single* number.  "45 (3)" is two numbers, though could
easily be given as 45-3 or something else and massaged in processing.

If we allow spaces inside @n, then won't people just naturally abuse this
element with real free text?  Isn't part of the point of datatypes to help
protect people from themselves?

-James
P.S. I'm frankly a bit ambivalent about this, but thought someone should at
least attempt to provide an opposing point of view.

-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk



More information about the tei-council mailing list