[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Finishing the XML-tagging discussion
> At 01:33 PM 3/20/00 -0500, Keith Moore wrote:
> >if you want an expression that matches anything ending in -xml,
> >as far as I can tell, existing http accept header semantics,
> >and existing conneg expressions, are not sufficient to recognize that.
> >if you want it to be more general and anticipate the possibility
> >of multiple frobs (not just -xml) then you need something like
> >a regular expression matching capability
> >(so you can look for things like "-xml(-|$)" )
> I think we may encountered a problem in our underlying viewpoints. You're
> talking about sending */*xml over the wire in headers, while I'm only
> talking about using */*xml to recognize XML documents when I get them.
I am talking about both, but I think they're both problems.
or to put it another way, if we're going to invent a new syntatical
convention for describing content-type characteristics, let's
pick one that actually works with content negotiation
rather than one which requires drastic changes to content
> I don't think the proposal as written breaks things any more than
> introducing a new MIME type would.
in a sense, it doesn't break anything. in another sense, it
creates a new feature of content-type names that can be exploited,
and people will demand that they be exploited. so it requires
changes of existing implementations. and if the -xml feature catches
on then it will creep into content-type negotiation schemes. this is
not an intended consequence, but it is a likely one.
> Compared to the parameter option you keep proposing, I'd say this causes
> almost zero problems as far as interoperability and compatibility are
interoperability and compatibility aren't as much my concern as
feature creep and its effect on content-negotiation structures.
> If user agents start requesting */*xml, we do have a problem.
why do you think they won't want to do that?
> that isn't what this I-D proposes - if users find that useful, they'll have
> to push for changes in the protocol infrastructure.
yes, but if such changes are to be made, then perhaps it would be a good
idea to pick a syntax for declaring such features that doesn't require
changes to the protocol infrastructure - or at least, to consider what
those infrastructure changes would need to look like and evaluate the
new syntax in light of those changes.
> All this suffix does is provide additional information identifying content
> as having an XML foundation. I don't believe it has any other
> implications, nor do I believe it will interfere with other developing
> standards for content negotiation.
and yet you just admitted that it would cause a problem if user agents
started requesting */*xml.