Re: Dates & Times (was Re: Future of HTML)

On 11 Apr 98, Carl Beeth <carl@beeth.com> wrote:

> >If we're going to discuss a way to notate dates and times to make them
> >more machine-friendly (mainly web robots,proxies,  intelligent agents,
> >and browsers) then we have to think/discuss what machines will do with
> >those dates.
> 
> Actually there are some interesting things that could be done if dates were
> machine readable

> Imagine yourself reading a web page about the next W3C conference. Among
> the information there will be dates, times, locations. Well, what do you do
> with this information. If you are interested, you might mark the dates and
> location in your calender.
> [..]

"This is a job for XML" said the man wearing a cape and tights.

Seriously, a "schedule" mark up language in XML would be a good thing.
Anything from calendars, conference schedules, broadcast media 
(radio/TV/netcasts), etc. could really make us of this. And even adding 
extensions so one can E-mail an appointment request/signup document to 
someone. Endless possibilities...

Of course mixing document types will get problematic. If I have a set of 
pages for an organization (with a consistent style/appearence) but a few 
of them mention upcoming events, how to include them?

1. use "Schedule Markup Document" with a style sheet that is consistent
   with the rest of the site's documents
2. similar to (1), but including the document as an OBJECT or IFRAME,
   or as an ENTITY in XML.
3. providing some kind of reference link in HTML (or another DOCTYPE)
   that can be imported into a calendar application, for example

    <P>Our <a HREF="NextParty.xml" TITLE="Acme's Next Corporate 
    Party">next corporate party will be September 4, 1998</A>.</P>

   Someone reading the document will expect a link with a further 
   description, which of course would be available. But it will be in a 
   format that will allow one to import the document into a calendar app.
   (This is probably the best way to go in the future; one could even use
   a server script that converts it to HTML on the fly if using a non-XML 
   browser.)

4. ...and probably a few other ways I haven't thought of.

A problem with implementing machine-readable dates in HTML is that it's 
suddenly adding features to HTML that goes beyond what it was designed 
for (as a *generic* markup language for the web). Is it better to add 
these automation features to HTML and not others? If so, which other 
automation features should be added to HTML.

> ...Our annual party will be on<SPAN DATA="schedule" DATE="05-06-97"
> DESCRIPTION="Acme inc's annual party">the 5th of june</SPAN>"...
> 
> There would probably need to be a lot other attributes just for Schedules like:
> [..]

I'm involved with web pages for a local radio station, as well as pages 
for an intranet that includes calendars for events and classes that 
includes enrollment/signups... so I'm *quite interested* in participating 
with a working group for a "Schedule Markup Language".

> Of course, similar things could be imagined for a postal addresses and
> probably many other data types

That's my point. If we add even a minimal of useful types (schedules, 
addresses/contact info, etc.) HTML will become bloated. So it's better to 
have a set of standard DOCTYPEs, perhaps connected to documents using the 
LINK element:  <LINK REL="XML-Contact" HREF="..."> which will contain 
marked up contact information related to the page. That is, any LINK 
element with a relation type beginning with "XML-" would be for specially 
marked up information relevant to that page's contents, that XML-aware 
browsers and other apps could make use of.

(Though in the case of contact information RDF may be a better solution.)

Rob

Received on Sunday, 12 April 1998 20:21:16 UTC