Frank Dawson wrote:
Larry Masinter wrote, in part:
I'm saying you definitely have a problem: you have a complex space
of possible objects:
NO, this is not a complex problem. This is an existing 20+ year old mail
enabled application. This nut has already been cracked for Internet
developers using the "text/calendar" content definition. I queried
Kurita-san and Paul Hoffman because I was interested in utilizing XML
representation of iCalendar. We have a DTD defined. It is an isomer of the
iCalendar standard format,
So, the mechanics and all the semantics of text/calendar are retained
but it merely uses a different syntax?
In that case, it would seem that something like text/xcalendar would
meet your needs, and that apart from the syntactic portion, the defining
specification would see "see text/calendar" in a great many places (or
have the same text copied, whatever).
There needs to be
some balance between an infinite number of media types/subtypes for each
transaction type and a smaller, managable number of media types for each
logical application object type.
Yes. This is the hierarchical model, as opposed to the flat model.
Parameters provide a third level of hierarchy below the content type and
content subtype levels.
As Ned has pointed out, this example and
other show that leaving "hooks" on the outside of the object wrapper is very
useful in providing a scalable, practical Internet solution using XML.
The hooks are particularly useful for specialised types such as
calendaring. For a more generic "this is a textual document marked up in
XML" type, the difficulty is finding hooks of suitable generality.
--
Chris