I think I pretty much agree with Jim here: an ISO date string is the most reliable thing to use for date content: it's simple, it's standardized, it's reliably parsed by computers, etc. Detailed XML markup for dates just frustrates authors and programmers. It's also the case that there is now lots of open-source code that does a good job of parsing date and time strings of various forms. If dates are being set by computers, then generating an ISO date string is usually the easiest thing to do. If they are being set via forms, again, the form can produce an ISO date (this is what typical calendar controls do, for example). Using XSD, RelaxNG, and Schematron we can define the lexical rules for both attribute values and element content (for XSD, only when the content allows only PCDATA). It is only in a pure-DTD context that we can't enforce lexical constraints on element content (and if it's not already possible, it would be relatively easy to generate Schematrons from RelaxNG or XSD schemas to validate lexical constraints for elements and attributes). At the moment DITA does not provide a unified markup model for capturing time information. There's the original markup from <critdates> and there's lcDuration that I can think of immediately. The Machine Industry TC put forward a proposal for parametric data that included timing information, but that proposal faltered for lack of support, if memory serves. (I think it's that proposal that I'm remembering as including discussion of capturing time information.) I think it would be reasonable to define a new base type, "date-time" that has the semantic of "contains some form of specification of a point in time", along with "date-time-range", with the content model (date-time,date-time), where the first child is the start time and the second is the end time. From this base we could specialize "iso-date-time" that is defined as containing an ISO date string and other specializers could create whatever they wanted. But as Kris emphasized on this week's call, it's also very late in day for any new proposals and this sort of seemingly simple thing can turn out to be quite complicated when you start to really push on the requirements and usage implications. Cheers, E. On 8/21/13 5:51 PM, "Jim Tivy" <
jimt@bluestream.com> wrote: > I was not likely there when you decided. > > I notice your spec part of the doc uses ISO 8601 but your examples have > slashes. > > goliveThe publication or general availability (GA) date, entered as > YYYY-MM-DD, where YYYY is the year, MM is the month from 01 to 12, and DD is > the day from 01-31. > > > golive="2/15/1999" > > > But I suggest we adopt 8601 which is also the XML Schema standard: > >
http://en.wikipedia.org/wiki/ISO_8601 > > As well, I would recommend that some examples specify the timezone content > is not widely exchangeable otherwise. I recommend using GMT for all dates but > some users may need to specify offsets. Offsets take the form of, for > example, -07:00 for San Franciso time. ³Z² is a nice short form for GMT > > eg: 2007-03-01T13:00:00Z > > Using just dates with no time can work for some people. > > The interpretation of a date is soft it does not refer to any particular time > and could be days off for some folks without a timezone. > > > From:
dita@lists.oasis-open.org [ mailto:
dita@lists.oasis-open.org ] On Behalf > Of Don R Day > Sent: August-21-13 1:24 PM > To:
dita@lists.oasis-open.org > Subject: Re: [dita] Previous discussion of/decision on generic date/time > markup? > > I recall a topic on recommending the use of ISO conventions for textual markup > in lieu of datatyped enforcement. Darned if I can find it now. However, our > early documentation for date-dependent attributes seems to rely on that > presumed convention. For example, see the attribute descriptions for > @modified, @golive, and @expiry in the <revised> element from the 1.0 spec: >
http://docs.oasis-open.org/dita/v1.0/langspec/revised.html > > The closest to any domain that might be worth using as a model would be the > bookchangehistory element's content (ie, <reviewed> or <approved>): >
http://docs.oasis-open.org/dita/v1.1/OS/langspec/langref/bookchangehistory.htm > l > > In general, the bookmeta designs for structured data tend to be > over-prescriptive for authoring in a regular XML editor that lacks form-based > affordances for such constructs. On the other hand, the template-based or > guideline-based input from 1.0 days was not always localization friendly or > verifiable. Fun. > > I'm not sure if these were the same background you recall. > -- > Don > > On 8/21/2013 2:50 PM, Eliot Kimber wrote: >> I dimly recall some discussion in the past of generic markup for dates and >> times, but I don't remember the details, other than nobody proposed a >> generic date and time markup domain. >> >> Unfortunately, it's not possible to search usefully on keywords like the >> "date" and "time" and "markup" so my attempt to search the mail archives was >> a failure. >> >> Does anyone have any memory of this discussion? >> >> Thanks, >> >> Eliot > -- Eliot Kimber Senior Solutions Architect, RSI Content Solutions "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368
www.rsicms.com www.rsuitecms.com Book: DITA For Practitioners, from XML Press,
http://xmlpress.net/publications/dita/practitioners-1/