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

[Syd Bauman]

> Zone=
> -----
> Question: Should the zone= attribute of <timeStruct> be retained as a
>           new zone= attribute of <time>?
> Answer: No.

The zone= attribute is no more (it hasn't been for awhile). In
addition, I've

* updated the prose of ST (The TEI infrastructure) that happened to
  refer to it as an example of data.enumerated.

* Replaced erroneous references to ISO 8601 with proper references to
  W3C Schema part 2.

* Replaced an erroneous reference to RELAXNG with correct reference to
  W3C Schema.


> Type=
> -----
> Question: Should the type= attribute of <dateStruct> and <timeStruct>
>           be retained?
> Solution: Yes; make <date> and <time> members of class att.typed (I
>           am the only one who complained that subtype= was overkill,
>           so ...)
and
> Type= of att.datePart
> ----- -- ------------
> Question: Should <day>, <distance>, <hour>, <minute>, <month>,
>           <occasion>, <second>, <week>, and <year>, have a type=
>           attribute?
> Answer:   No, remove type= from att.datePart.
>           (Note: if they *should* have type=, they should get it from
>           att.typed, although I still am queasy about subtype=.)

Done.

Except that I put <day>, <distance>, <occasion>, and <offset> into
att.typed.


> Ranges
> ------
> Problem: We need to think through <dateRange> and <timeRange> with
>          respect to data.duration, ISO 8601 range formats, and
>          notBefore= & notAfter=.
> 
> 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

Done, mildly differently:
* Added <date> and <time> to att.datable
* split value= of att.datePart into value= and dur=
  - also fixed <valDesc>s of other two occurences of dur=, which
    perhaps with this one should be factored into a clas of its own
  - decided unilaterally that specification of both value= and dur=
    indicates a span of time by start time & duration
* deleted <dateRange> and <timeRange>
  - this included moving from= and to= into att.datable
  - Note to Lou: I left the dateRange.xml and timeRange.xml files
    in the SF subversion repository as we may want to copy the exact=
    attribute out of it before nuking it
* After talking it over with Lou, I did *not* implement any method for
  validation  that (  value=  and/or  dur= )  OR  ( notBefore=  and/or
  notAfter= ) is present, but not both


> <offset>
> --------
> Question: Should <offset> be a member of att.datePart?
> Answer:   No, remove it.

Done.


> Full= of att.datePart
> ----- -- ------------
> Question: Should full= exist?
> Answer:  No, kill it.

Done.


> Precision, accuracy, exactness
> ---------- --------- ---------
> Problem: We still need to sort out this precision/exactness stuff.

Still true.