[tei-council] death of <*Struct>: pending problems & suggested solutions

[Syd Bauman]

> I have no problem with using the ISO 8601 range formats.

OK, but the question is, do you have a problem with my proposal
(which does not use the ISO 8601 range formats, but rather uses the
W3C-like notBefore= and notAfter= attributes, OR a value= and a
dur= (which, if combined with a solidus between them, would be the
same as an ISO 8601 4.4.4.3 representation))? 


> On dateRange and timeRange are @notBefore and @notAfter replacing
> @from and @to? I.e. I'm assuming if we just end up with date/time
> that there won't be a @from and @to?

Uhhh ... good question. I guess I was presuming from= and to= would
be dropped, but to be honest I don't have strong feelings one way or
the other at the moment. (Sebastian had indicated earlier that
personagrphy wanted from= and to= in att.datable, but I never heard
anything else about it, and I don't think the personography model
makes use of those attrs.)


> > Proposal: * delete <dateRange> and <timeRange>
> >           * add <date> and <time> to att.datable (thus they get
> >             notBefore= and notAfter=)
> >           * alter att.datePart so that rather than having
> >             attribute value { data.temporal | data.duration }
> >             it defines two attributes
> >             attribute value { data.temporal }
> >             attribute dur { data.duration }
> >           * add Schematron rule to <date> and <time> that insists
> >             that either ( value= and/or dur= ) OR ( notBefore= and/or
> >             notAfter= ) is present, but not both
> > 
> >           ALTERNATIVE: 
> >           Rather than having a Schematron rule, could plop all four
> >           attributes into alternate pairs in a single class. At least
> >           I think this is supposed to work, but at the moment it
> >           generates an invalid schema. (I've sent Sebastian separate
> >           mail.) 
> 
> If this can be done without a schematron rule, then that is certainly better.
> Although I'm slightly torn about it, I think getting rid of dateRange/timeRange
> in favour of having just having the ability to indicate this on date/time is a
> beneficial step.

Check.