[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finishing the XML-tagging discussion



> > > > One alternative - not necessarily one I am advocating, but just
> listing for
> > > > completeness - is to use a similar approach but swapped round:
> > > >
> > > > image/svg;ContentLanguage=xml
> >
> > > I favor something like this.  it seems like it will interact more
> > > cleanly with content negotiation mechanisms (as opposed to those
> > > mechanisms having to acquire new pattern-matching facilities)
> >
> > > it's true that as MIME is architected the parameter space is on a
> > > per-content-type basis.  but I don't see any great harm if we define
> > > some global parameter name space (say, parameter names that begin
> > > with "$" are global).  Then we could do something like:
> >
> > > content-type: image/svg; $superclass="application/xml"

> ned - i agree with your take that having global parameters is a major change
> to MIME.

> suppose we were just to have something like:

>     Content-type: image/svg; representation="xml"

> where "representation" is just a plain old MIME parameter.

> would you object to something along these lines?

Yes. Most of the problems I have with global parameter still apply to this
usage.

If we absolutely have to do this with a separate piece of information, I would
opt for a content-feature tag. That way there's a clear delineation between
when feature information is or is not present, and we don't mess up MIME
parameter space. And we need the feature tag anyway for negotiation purposes.

I still strongly prefer the suffix, however.

				Ned