At 05:40 PM 3/11/00 -0800, Paul Hoffman / IMC wrote:
1. A web crawler building a full-text index
2. An XLink processor building a topological map a la Google
3. A rules-driven firewall filter deciding whether to let something
through
4. A schema-driven datatype-checker
Of these four, only (3) makes sense for IOTP.
Well, I'm claiming the thesis behind XML is that you can't prejudge what
might or might not make sense tomorrow for the data objects you create
today. Having said that, I'm prepared to believe that you're right
as regards IOTP.
(3) is pretty psychedelic. Firewalls that look at MIME types but not the
content are so horribly insecure as to not need further discussion.
That's not it; one can envision a firewall that checks those data
objects known to be XML-encoded, whatever their primary media types,
for certain patterns of XML markup that are regarded as blessed or
unblessed. In particular, given that there is likely to be XML
markup that has cross-application inclusion semantics, one can
envision firewalls disallowing such inclusions whatever the application.
Not only can we wait for "the next one" on this topic, we have another
example of a group that doesn't feel much inclined towards the utility of
the application/foo-xml solution for their protocol.
I'm not trying to be difficult, but once again, one of the central
theses in the use of XML is explicitly to minimize the damage due to
the fact that very few groups, in designing a data format, bother to take
the trouble to ensure that it might be reusable for unforeseen
purposes at a later date. Thus, the fact that this particular group
says they don't need this particular flag for their particular application
is not very relevant to the argument as to whether the -xml suffix is
a good idea. -Tim