[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?
Although it is late in the DITA 1.3 cycle, with the introduction of yet another set of elements that need date/time with the release management domain, it would be useful for us to have a standard element set to use rather than adding to the inconsistency. Just my $.02. Amber Amber Swope dita specialist <dita strategies> 503.922.3038 amber@ditastrategies.com -----Original Message----- From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Eliot Kimber Sent: Thursday, August 22, 2013 6:55 AM To: dita 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 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.h tm> 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/ --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]