OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Previous discussion of/decision on generic date/time markup?

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

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.



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>):
> 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
Book: DITA For Practitioners, from XML Press,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]