[tei-council] adding (non-)Struct elements to <date> & <time>

[Syd Bauman]

> >> 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?