Re: Finishing the XML-tagging discussion

[Keith Moore <moore@xxxxxxxxxx>]

> 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 
negotiation frameworks.

> 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
> concerned.

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?

> However,
> 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.

Keith