Le 30-mars-09 à 22:39, Chris Lilley a écrit : > PL> Without being certain the three mime-types we would propose > could be: > PL> - application/mathml+xml (this one for sure) > PL> - application/presentation+mathml+xml > PL> - application/content+mathml+xml > > I believe that the "+" is reserved, so I would suggest > - application/mathml+xml (this one for sure) > - application/presentation-mathml+xml > - application/content-mathml+xml I guess I should not argue with you but the usage of + in RFC 4288 is explained as: > In accordance with the rules specified in [RFC3023], media subtypes > that do not represent XML entities MUST NOT be given a name that > ends with the "+xml" suffix. More generally, "+suffix" constructs > should be used with care, given the possibility of conflicts with > future suffix definitions. And in this case, I believe the care for future suffix definition is cared for: we really expect any mime-type following the glob application/*+mathml +xml to be related to MathML! > PL> The hot debate is whether 3 mime-types run a risk of being > refused by > PL> IETF or W3C liaisons at a relatively late stage. > > Yes, there is that risk. In particular is something that accepts the > first one expected to accept the other two (subset?) ones as well? I will try to discuss this on ietf-types mailing-list if it's ok with everyone. I strongly believe that specialized mime-types will be useful in the future! > The only analogous situation I can think of is X3D which has three > media types for three different encodings: > model/x3d+xml [...] > While yours is more a supertype plus two subtypes Right, quite different. It may be we're the first to try that, I'd ask this on the ietf-types list. paul
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:33:26 GMT