[tei-council] adding (non-)Struct elements to <date> & <time>
Syd Bauman
Syd_Bauman at Brown.edu
Sun Jun 11 10:08:42 EDT 2006
> >> P.P.P.S. Is there an argument for adding <date> and <time> to
> >> att.datePart other than mimicking the properties of <dateStruct>
> >> and <timeStruct>? That is, do we anticipate needing those
> >> attributes for the elements in question?
> > The attributes are:
> > * value=
> > Makes a lot of sense to have it from a class, but it does mean
> > enduring the (unwanted?) side-effect of permitting xsd:duration
> > values.
> > * type=
> > I think there is an argument for keeping type= on <date> &
> > <time>.
> > * full=
> > I've yet to be convinced this attribute should be retained.
> I'd be happy with the following resolution of these issues:
> - remove xsd:duration alternate from the @value attribute
I have to admit, I'm a bit queasy about this. Certainly <distance>
must be able to be regularized to xsd:duration. Are we OK removing
the duration from each of <day>, <hour>, <minute>, <month>,
<occasion>, <offset>, <second>, <week>, and <year>?
Why is <offset> in this list at all? I.e., I think maybe <offset>
should not be a member of att.datePart.
> - if @type is to be retained (and I think it should) it should be
> inherited from the typed class, or specified explicitly. Let's not
> have it inheritable from more than one class, at least!
I'm inclined to agree, but that adds a subtype= attribute, too. If
we're not really sure how type= would be used, it seems quite
superfluous to have a subtype=.
> - @full is otiose, redundant, rebarbative and Should Go Now.
Any objections?
More information about the tei-council
mailing list