Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt

[Ned Freed <[e-mail]>]

> Hi,
> On Wed, Apr 11, 2012 at 09:27:22AM +0300, Zach Shelby wrote:
> >
> > This draft is defining what you must define when registering a given foo+exi, thus I think we are in line with making sure constraints are specified. This draft *does not* intend to define a generic +exi suffix.


> The title of the draft is "The +exi Media Type Suffix". Is there some
> subtlety that I am missing entirely?

If such a subtlety is there, I'm missing it too.

> I don't think you can override or
> define another draft for +exi once one is registered, that's the point
> of registering.

Exactly.

> Let me clarify my point: I think defining a +exi suffix for schema-informed
> mode saying "you must specify the form of schemaID that you are using" would
> be a huge mistake. It is (1) not useful, since the EXI 1.0 spec already says
> you have to define schemaID for your application, (2) harmful, since it tries
> to redefine the mechanism for options that is already defined in EXI 1.0,
> at least for the schema-informed mode.

I remain to be convinced that +exi is a good idea or even allowable, but
not for these reasons. The problem as I see it is that the point of + suffixes
is to allow some degree of processing even though you don't know the specifics
of the type. But this doesn't seem to be the case for +exi.

> What's wrong with using Content-Encoding, exactly? Semantically, EXI *is* xml,
> so having something like foo+xml vs. foo+exi does not make sense, while
> *encoding* foo+xml with EXI makes sense.

The main problem with encodings is that they are not intended to have this sort
of structure. And more to the point, I doubt very much that existing software
is prepared to deal with taking apart structured encoding names and figuring
out if they have the necessary schema available.

				Ned