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