#139 Remove redundant iso-* attributes

AMBER
closed
nobody
None
5
2008-12-09
2008-08-17
Lou Burnard
No

The iso-when attribute can contain a single string which represents any or all of the features represented by attributes iso-from iso-to or iso-dur (this is not however true of the equivalent w3c-* attributes). I propose therefore that we retain only the iso-when attribute and explicitly add it as an alternative to the combination of w3c attributes. This would both avoid the need to define two attributes classes and make explicit that the iso dating mechanism is intended to be used as an alternative to the w3c one, not as a supplement to it.

See brief discussion at http://lists.village.virginia.edu/pipermail/tei-council/2008/009879.html

Discussion

  • Lou Burnard

    Lou Burnard - 2008-08-17
    • milestone: --> AMBER
     
  • Syd Bauman

    Syd Bauman - 2008-08-18

    Logged In: YES
    user_id=686243
    Originator: NO

    The proposal does not say what happens to iso-notBefore= and
    iso-notAfter=. Since AFAIK ISO 8601:2004 does not provide any syntax
    that would provide the same functionality, I would say those
    attributes have to stay.

    As for iso-to=, iso-from=, and iso-dur=, I don't see any strong
    arguments for either keeping them or killing them. As stated in the
    original post, the reason for killing them is just to have fewer
    attributes, and thus a less confusing spec. Killing them also
    eliminates the possibility of certain kinds of combinatorial problems,
    like
    <date iso-from="2008-08-11/P5D"/>
    <date iso-from="2008-08-11" iso-to="2008-08-15" iso-dur="P18D"/>
    etc.

    One argument in favor of keeping them is that it makes it much easier
    to switch from ISO to W3C format when that's needed. If you have a
    document that has
    <time from-iso="14:30" to-iso="21:50"/>
    it's pretty easy to convert that to
    <time from="14:30:00" to="21:50:00"/>
    (see attached stylesheet).
    While it's not impossible, converting
    <time when-iso="14:30/21:50"/>
    would be somewhat harder, and converting
    <time when-iso="14:30/PT7H20M"/>
    would be harder still.

    File Added: when-iso_to_when.xslt

     
  • Syd Bauman

    Syd Bauman - 2008-08-18

    stylesheet to convert when-sio=, from-iso=, to-iso=, notBefore-iso=, and notAfter-iso= with imprecise times to the corresponding W3C attribute with a falsely precise time.

     
  • Syd Bauman

    Syd Bauman - 2008-08-19

    Logged In: YES
    user_id=686243
    Originator: NO

    BTW, whether the from-iso=, to-iso=, and dur-iso= attributes are nuked or not, I still think it would be a good idea to formalize the prohibition against having both a standard (W3C) temporal attribute and the corresponding ISO temporal attribute. I.e., something like the following.

    <pattern name="notBothISOandW3C">
    <rule context="*[@when|@when-iso|@from|@from-iso|@to|@to-iso|@notBefore|@notBefore-iso|@notAfter|@notAfter-iso|@dur|@dur-iso]">
    <report test="@when and @when-iso">
    An element should not have both when= and when-iso= specified, but an occurence of &lt;<name/>&gt; does.
    </report>
    <report test="@from and @from-iso">
    An element should not have both from= and from-iso= specified, but an occurence of &lt;<name/>&gt; does.
    </report>
    <report test="@to and @to-iso">
    An element should not have both to= and to-iso= specified, but an occurence of &lt;<name/>&gt; does.
    </report>
    <report test="@notBefore and @notBefore-iso">
    An element should not have both notBefore= and notBefore-iso= specified, but an occurence of &lt;<name/>&gt; does.
    </report>
    <report test="@notAfter and @notAfter-iso">
    An element should not have both notAfter= and notAfter-iso= specified, but an occurence of &lt;<name/>&gt; does.
    </report>
    <report test="@dur and @dur-iso">
    An element should not have both dur= and dur-iso= specified, but an occurence of &lt;<name/>&gt; does.
    </report>
    </rule>
    </pattern>

    (The above code was written based on all the *-iso= attributes, and obviously would need to be modified if some of those were deleted.)

     
  • David Sewell

    David Sewell - 2008-08-21

    Logged In: YES
    user_id=35379
    Originator: NO

    At the same time that this is done (if it is done), the declaration for data.temporal.iso needs to be tightened up if possible to prevent validation of nonsense data. Because it allows a choice of various datatypes plus

    token { pattern = "[0-9.,DHMPRSTWYZ/:+\-]+" }

    the consequence is that gibberish like <date when-iso="2008-Z::Z-33-15"> validates. It ought to be possible to create a Relax NG schema pattern that would allow any valid ISO 8601 date representation, but only those.

     
  • Syd Bauman

    Syd Bauman - 2008-08-21

    Logged In: YES
    user_id=686243
    Originator: NO

    DS> ... the declaration for data.temporal.iso needs to be tightened up
    DS> if possible ...
    DS> It ought to be possible to create a Relax NG schema pattern that
    DS> would allow any valid ISO 8601 date representation, but only
    DS> those.

    It certainly should be possible to tighten up data.temporal.iso a lot.
    I am not sure, but I think it may even be possible to match only ISO
    8601:2004 date representations and nothing else.

    The following is from the source of data.temporal.iso:

    My expectation is to replace this catch-all pattern with a series
    of patterns to match the various extended formats of 8601. The two
    commented-out patterns above are a helpful start. Either that,
    or if someone comes up with a real RELAX NG datatype, use it.
    :-) -- sb

    So week dates with times, intervals, and recurring intervals still
    need to have patterns created. If Council so wishes I would be willing
    to work on these.

     
  • David Sewell

    David Sewell - 2008-08-25

    Logged In: YES
    user_id=35379
    Originator: NO

    In addition, @period should be moved out of the class att.datable.w3c to become a direct member of att.datable, as it is an independent attribute, unconnected with the w3c/iso attributes that represent quantifiable values.

     
  • Syd Bauman

    Syd Bauman - 2008-11-01

    List of ISO8601 features and whether TEI can represent w/o *-iso attrs

     
  • Syd Bauman

    Syd Bauman - 2008-11-01

    Program to write a RELAX NG schema fragment that could be used as part of a datatype to constrain to an ISO 8601 representation.

     
  • Lou Burnard

    Lou Burnard - 2008-12-09
    • status: open --> closed
     
  • Lou Burnard

    Lou Burnard - 2008-12-09

    1. For the time being, take no action on the request. The main reason is
    that Lou's initial request makes the assumption that, given the
    flexibility of ISO 8601 syntax, @when-iso is capable of being fully
    synonymous with any of the other att.datable.iso attributes (largely
    because the syntax permits (a) the expression of a duration, and (b) the
    expression of from-to intervals using a solidus (/) separator. But in
    fact there is no way in ISO 8601 syntax to express the semantics of
    "notBefore" and "notAfter", so @notBefore-iso and @notAfter-iso could
    not be eliminated without loss of expressive ability, which defeats the
    goal of conflating the *-iso atttributes into att.datable.

    2. The main thing you can do with full ISO 8601 date/time syntax that
    you can't do with the W3C Schema datatype subset of ISO 8601, beside
    expressing intervals using a "/" separator, is to represent dates and
    times with reduced accuracy. For example, to express "from 2 to 3 p.m.",
    W3C syntax requires
    <time from="14:00:00" to="15:00:00"/>
    whereas with ISO 8601 you can say
    <time from-iso="T14" to="T15"/>
    which some people prefer as it makes no implicit claim to precision.

    Syd thinks that if the main (or only) thing we get out of adding ISO
    8601 syntax is a way of expessing imprecise times, we should investigate
    whether we can eliminate the *-iso attribute series in favor of some
    other way, using new attributes, to express the same thing.

    In the meantime, he and I are going to see whether we think we can come
    up with a regular expression pattern that more accurately constrains the
    allowable values for the *-iso series, as the current pattern facet is
    too permissive.

    I'd also add that, having gone to the trouble of adding the whole
    att.datable.iso class for P5, it would be a bit odd to withdraw it
    mid-stream, so I don't see this as anything that could happen before P6
    in any case. (For reference, the first proposal for adding an ISO class
    was in Syd's Council email from 2007-01:

    http://lists.village.virginia.edu/pipermail/tei-council/2007/006725.html

    )

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks