On Mon, 13 Mar 2000 08:02:11 PST, ned(_dot_)freed(_at_)innosoft(_dot_)com
said:
Specifically, in order for this to work sending agents have to generate a
field
saying "this thing is XML". In order to do tis they have to have a list of
all
XML-based types. And this is exactly the list we're trying to avoid having.
Huh?
If I have a sending agent that knows how to generate a foobar type, and
a foobar-using-xml type, then *whatever* scheme we use to flag xml, I
have enough information to flag that THIS type is xml.
No, as I said before, all you have is an (application)->MIME type mapping.
Unless the fact that the type is XML is implicit in the MIME type
name you don't necessarily know it is XML.
I don't need to
know whether a frobozz-using-xml type exists, or is registered, or is
being used via private agreement with x-frobozz types.
You either need to know that it is XML or else you'd have to examine
the data. And we try and avoid the latter...
Compare this with embedding this information in the content-type. There's
already a list of (some file characteristic)->content-type mappings in most
MIME applications. So no new list is needed. The information simply gets
embedded in the existing list.
There's only one snag here - semi-legacy software. If we decide that
we should just use application/xml and tehn a Content-Feature: or
whatever tag to flag specific ideosyncracies/schemas for the object,
then once deployed, a receipient will be able to get at *least* the
base application/xml level of support no matter WHAT future updates of
his software he makes.
Not if the legacy software doesn't know to generate the content-feature
field. And this is going to take a fairly serious redesign to generate
in a lot of places.
I thought the whole point of XML was that the
reciepient will be able to do basic operations (such as "hmm.. forward
all THIS stuff tagged with finance schema to Fred, and all the
stuff that looks like shop-floor-machining stuff to Larry") without
knowing what the heck the data IS.
I fail to see what this has to do with anything.
If you start using application/iotp-xml, and application/foo-xml,
and application/frobozz-xml, until the recipient updates his table,
he gets punted ALL the way back to application/octet-stream.
Not if he has an application that looks for the suffix. And adding support for
this to legacy applications is far easier than adding support at the front end
to generate a new field *and* adding support at the back end to examine this
new field and act on it.
That's a phone call to our help desk to figure out how to open
this unidentified file. Then another to find out how to install
the table update for foobar-xml. Then another to find out how
to install the application to get rid of the "application not found"
box.... You get the idea. ;)
OK, now consider the case where we use a content-feature field. You still
have to do all of this *and* you need to update the dispatcher with a
major new release *and* you need to convince the person sending the
message to update their software as well.
/Valdis (who left user services mostly because he hated those kinds
of phone calls ;)
Well, I myself haven't left, and believe me, I don't want to deal with the
upgrade nightmare a content-feature field implies.
Ned