[tei-council] attribute datatypes

[Lou Burnard]

OK, I will add  a ticket for the ones that are not just corrigible 
errors (i.e. 1 and 2, which I have just fixed)

Re @interval -- "interesting" as in "interesting times" methinks -- 
Personally, I cannot get my head round the idea of any interval which is 
not regular, but in any case if this is a distinction worth making 
(between regular and irregular that is) it ought to be a separate  
attribute, shirley.


On 24/02/13 19:38, Martin Holmes wrote:
> I definitely agree with the principle. The two @interval attributes are
> interesting, though; in addition to a float (in both cases), <when>
> allows a string value of "unknown", while <timeline> has possible values
> of "regular" and "irregular". If we were to unify those under a single
> macro, those text values would have to be shared, and I'm not sure
> that's ideal. <when interval="irregular"> seems meaningless to me.
>
> Cheers,
> Martin
>
> On 13-02-24 10:43 AM, Lou Burnard wrote:
>> Just a word (well, several) on attribute datatypes.
>>
>> I believe our policy to be that attributes define their datatype
>> indirectly by refering to one of the existing data.xxx macros, which
>> are then mapped to a RELAXNG expression. This additional layer of
>> indirection allows us to say something about the datatype
>> independently of how it's currently constrained by the RELAXNG
>> schemas, and is thus, I contend, A Good Thing, which should be applied
>> consistently. As, for the most part, it is. However I have
>> discovered the following which appear to me to be anomalous:
>>
>> 1. source at readFrom is defined directly as "anyURI" which is a macro,
>> not a datatype: It should be corrected to data.pointer
>>
>> 2. att.lexicographic at opt and fDecl at optional  are both defined as
>> boolean, but should probably be data.truthValue
>>
>> 3. timeline at interval and when at interval are both defined using ad
>> hoc RNG constructs (but not identical ones); we should define a
>> data.interval which is consistent.
>>
>> 4. language at usage uses an adhoc RNG datatype directly; we should
>> define a new "data.percentage" macro for it (and look for other cases
>> where this might be used)
>>
>> 5. application at version uses an  adhoc RNG expression, which surely ought
>> to be replaced by a "data.versionNum" macro
>>
>> 6. Several attributes [moduleRef at except and @include;
>> att.identified at module; @key, on classRef, elementRef, macroRef, and
>> moduleRef; moduleRef at prefix] use the built in RNG datatype "NCName". It
>> might
>> be more consistent to define  our own macro "data.xmlName" vel sim.
>>
>> 7. That old bugbear rng:text is still used on most of the attributes
>> delivered by att.lexicographic (expand, norm, orig, split, and
>> value); two attributes which hold regexp values
>> (att.patternReplacement at replacementPattern and att.scoping at match);
>> also on  refState at delim, and valItem at ident.  I think we should have
>> just one datatype for "string of words to be treated as a single entity" and
>> use that for some of these; for the regexpes surely we should have
>> data.regexp.
>>
>>
>> 8. Many many attributes currently include <valList>s of various levels
>> of closure. I felt too faint to check (and I think someone else
>> already has), but they should all also have a datatype of data.enumerated.
>>
>> Yes, I know this should be a ticket or several such. But I thought it
>> might be a good idea to check that we're all agreed on the principle
>> before setting in motion its consequences.
>>