Hello mime-types experts, in the W3C Math working group, a hot debate is happening about the types of content. MathML defines two types of content in its specification, MathML- content and MathML-presentation. They are both specified in the same spec which also offers ways to combine them. In the future chapter 6 (draft at http://monet.nag.co.uk/~dpc/draft-spec/chapter6.html ), one can see that the need arises to qualify MathML objects of the two different types with a different name on the clipboard and this is agreed upon in the group. What is not agreed upon is whether the final spec should include a form for just one generic mime-type or three so as to allow negotiation similar to the clipboard: - application/presentation+mathml+xml - application/content+mathml+xml - application/mathml+xml The two first are the specific types, the last one is the generic type; our registration would append the form(s) at RFC 4288 within a normative part in the MathML spec. It's pretty clear we shall specify that the generic type should always be offered if a specific type is offered and, similarly, the generic type should be delivered if it's not clear that the specific type is supported. We do not have yet a big set of scenarios that depend on a content- negotiation where the knowledge of a specific mime-type is the sole enabler instead of "just accepting any MathML and try to do your best with it". Here are my questions: - do you see any danger in having three mime-types if we have the provision above? - is there a chance our registration for three mime-types is rejected for other reasons? thanks in advance paul
On Sat, Apr 4, 2009 at 7:30 AM, Paul Libbrecht <paul@activemath.org> wrote:
Hello mime-types experts,
We call them media types now 8-)
Here are my questions: - do you see any danger in having three mime-types if we have the provision above?
I wouldn't use the word "danger", but I personally don't see much value in having three media types based on your explanation and the spec itself. The only reason I could see for needing another one (not necessarily two more) would be if there were agents which would only be implementing one of the two forms of MathML document and, most importantly, were unable to understand documents which contained the form they didn't implement. But that doesn' t appear to be the case.
- is there a chance our registration for three mime-types is rejected for other reasons?
The use of "+" is incorrect in a couple of ways. First, that the convention is used to indicate the possibility of generic processing by indication of a generic format, such as XML or JSON; "mathml" isn't such a generic format. Second, no meaning has yet been assigned to the use of multiple "+" segments. "application/mathml-presentation+xml" would be better. Mark.
I agree with what Mark said. I guess you want multiple clipboard types because you want to give the receiving application a chance to use either of the two representations. For media types, that would correspond to the situation that you want your user agent to tell you which representation it prefers, and the server to send one or the other depending on the request from the user agent. Do you see a possibility for such situations? Regards, Martin. On 2009/04/06 6:13, Mark Baker wrote:
On Sat, Apr 4, 2009 at 7:30 AM, Paul Libbrecht<paul@activemath.org> wrote:
Hello mime-types experts,
We call them media types now 8-)
Here are my questions: - do you see any danger in having three mime-types if we have the provision above?
I wouldn't use the word "danger", but I personally don't see much value in having three media types based on your explanation and the spec itself. The only reason I could see for needing another one (not necessarily two more) would be if there were agents which would only be implementing one of the two forms of MathML document and, most importantly, were unable to understand documents which contained the form they didn't implement. But that doesn' t appear to be the case.
- is there a chance our registration for three mime-types is rejected for other reasons?
The use of "+" is incorrect in a couple of ways. First, that the convention is used to indicate the possibility of generic processing by indication of a generic format, such as XML or JSON; "mathml" isn't such a generic format. Second, no meaning has yet been assigned to the use of multiple "+" segments. "application/mathml-presentation+xml" would be better.
Mark.
-- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Le 05-avr.-09 à 23:13, Mark Baker a écrit :
We call them media types now 8-)
noted (changed subject also).
Here are my questions: - do you see any danger in having three mime-types if we have the provision above?
I wouldn't use the word "danger", but I personally don't see much value in having three media types based on your explanation and the spec itself. The only reason I could see for needing another one (not necessarily two more) would be if there were agents which would only be implementing one of the two forms of MathML document and, most importantly, were unable to understand documents which contained the form they didn't implement. But that doesn' t appear to be the case.
Martin J. Dürst replied:
I agree with what Mark said.
Sure, that's the question and sure there are such agents even though nowadays they mostly do both. For example giving only presentation into Maple works "often" (in an anglo-saxon world) but often interpretes wrong (e.g. with a limit). The conversions are ready, they're just impossible to do fully. The same would happen at the http level. Most tools can process all the three forms (they're all MathML after all) but they would process far better and fail less if they would know the specific types. Martin J. Dürst also wrote:
I guess you want multiple clipboard types because you want to give the receiving application a chance to use either of the two representations. For media types, that would correspond to the situation that you want your user agent to tell you which representation it prefers, and the server to send one or the other depending on the request from the user agent.
I think this is the very best explanation I can see for the case of content-negotiation for http: give a chance to the client to indicate its preference and to the server to actually be able to do the effort of the conversion better than "just doing it generic". One of the other example would be a component displaying a formula that would use the same URL as a content consumer (a function plotter for example) but interested to display that formula to clients in their own language (or context of notation).
- is there a chance our registration for three mime-types is rejected for other reasons?
The use of "+" is incorrect in a couple of ways. First, that the convention is used to indicate the possibility of generic processing by indication of a generic format, such as XML or JSON; "mathml" isn't such a generic format.
My feeling was different: mathml+xml definitely tasted generic enough to what it names. But if you say so, we can certainly change the first +s to -! Nothing's fixed here. paul
Aside of the question of the "necessity" of specific media-types, the most important question is the "eligibility" of such a request: Many in our group are convinced that a request for three media-types would be rejected and this only after the last-call draft this summer. Can members on this list answer the question of the eligibility ? paul Le 06-avr.-09 à 11:08, Paul Libbrecht a écrit :
Martin J. Dürst also wrote:
I guess you want multiple clipboard types because you want to give the receiving application a chance to use either of the two representations. For media types, that would correspond to the situation that you want your user agent to tell you which representation it prefers, and the server to send one or the other depending on the request from the user agent.
I think this is the very best explanation I can see for the case of content-negotiation for http: give a chance to the client to indicate its preference and to the server to actually be able to do the effort of the conversion better than "just doing it generic".
The Expert Reviewer for mime type registrations is Ned Freed, so he has the last say. My personal opinion is that either one or three types should be fine, and that probably the WG has the most expertise to decide this, but that you should really consider what others on this list (in particular Mark) said. Regards, Martin. On 2009/04/09 0:29, Paul Libbrecht wrote:
Aside of the question of the "necessity" of specific media-types, the most important question is the "eligibility" of such a request:
Many in our group are convinced that a request for three media-types would be rejected and this only after the last-call draft this summer.
Can members on this list answer the question of the eligibility ?
paul
Le 06-avr.-09 à 11:08, Paul Libbrecht a écrit :
Martin J. Dürst also wrote:
I guess you want multiple clipboard types because you want to give the receiving application a chance to use either of the two representations. For media types, that would correspond to the situation that you want your user agent to tell you which representation it prefers, and the server to send one or the other depending on the request from the user agent.
I think this is the very best explanation I can see for the case of content-negotiation for http: give a chance to the client to indicate its preference and to the server to actually be able to do the effort of the conversion better than "just doing it generic".
-- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
The Expert Reviewer for mime type registrations is Ned Freed, so he has the last say.
That's correct for types registered through the IANA process. Since these types appear to be the standards tree (no vnd. or prs. prefix), that requires IESG processing, which is not my baliwick. FWIW, in the case of IANA registered types, my job is to apply the criteria spelled out in the relevant registration procedures. AFAIK there isn't a lot of guidance in there as to when it's appropriate to use multiple types versus, say, a single parameterized type. So, absent a clear indication that what's happening are multiple types being defined for the same thing, I would allow all three types to be registered. But as I said, these are standards tree registrations so it isn't my call in any case.
My personal opinion is that either one or three types should be fine, and that probably the WG has the most expertise to decide this, but that you should really consider what others on this list (in particular Mark) said.
Mark's point was, as I recall, the presence of +mathml in the type name. That is indeed somewhat problematic and I would ask it to be changed if I were the reviwer. A -xmathml+xml suffix would be fine though. Ned
Le 09-avr.-09 à 17:35, Ned Freed a écrit :
The Expert Reviewer for mime type registrations is Ned Freed, so he has the last say.
That's correct for types registered through the IANA process. Since these types appear to be the standards tree (no vnd. or prs. prefix), that requires IESG processing, which is not my baliwick.
I understand the W3C liaison will do this part.
FWIW, in the case of IANA registered types, my job is to apply the criteria spelled out in the relevant registration procedures. AFAIK there isn't a lot of guidance in there as to when it's appropriate to use multiple types versus, say, a single parameterized type. So, absent a clear indication that what's happening are multiple types being defined for the same thing, I would allow all three types to be registered. But as I said, these are standards tree registrations so it isn't my call in any case.
some indicated that lack of implement (or "significant" implementations?) could be a critical factor. is it the case?
My personal opinion is that either one or three types should be fine, and that probably the WG has the most expertise to decide this, but that you should really consider what others on this list (in particular Mark) said.
Mark's point was, as I recall, the presence of +mathml in the type name. That is indeed somewhat problematic and I would ask it to be changed if I were the reviwer. A -xmathml+xml suffix would be fine though.
I have now drafted a first version of the forms for three types: W3C members can access at: http://www.w3.org/Math/Group/wiki/MimeForms the public at: http://www.activemath.org/~paul/tmp/media-type-regs-draft.html I have changed the subtypes to mathml-presentation+xml and mathml- content+xml. Feedback welcome. If all goes well, this will slip in the next working draft of MathML3. paul
Le 09-avr.-09 à 17:35, Ned Freed a écrit :
The Expert Reviewer for mime type registrations is Ned Freed, so he has the last say.
That's correct for types registered through the IANA process. Since these types appear to be the standards tree (no vnd. or prs. prefix), that requires IESG processing, which is not my baliwick.
I understand the W3C liaison will do this part.
FWIW, in the case of IANA registered types, my job is to apply the criteria spelled out in the relevant registration procedures. AFAIK there isn't a lot of guidance in there as to when it's appropriate to use multiple types versus, say, a single parameterized type. So, absent a clear indication that what's happening are multiple types being defined for the same thing, I would allow all three types to be registered. But as I said, these are standards tree registrations so it isn't my call in any case.
some indicated that lack of implement (or "significant" implementations?) could be a critical factor. is it the case?
For vnd. and prs. media types, no, it is not a factor. Indeed, since we want to encourage consistent naming it often makes sense to get the names nailed down very early, so we would not want this to be a requirement. While there are a some exceptions, we generally don't look for extensive implementation before approving documents as proposed standards in the IETF, including documents that register media types. (Implementation experience does come into play later in the process though.) However, this is W3C work and I don't know what criteria the W3C use in this case.
My personal opinion is that either one or three types should be fine, and that probably the WG has the most expertise to decide this, but that you should really consider what others on this list (in particular Mark) said.
Mark's point was, as I recall, the presence of +mathml in the type name. That is indeed somewhat problematic and I would ask it to be changed if I were the reviwer. A -xmathml+xml suffix would be fine though.
I have now drafted a first version of the forms for three types:
W3C members can access at: http://www.w3.org/Math/Group/wiki/MimeForms the public at: http://www.activemath.org/~paul/tmp/media-type-regs-draft.html
I have changed the subtypes to mathml-presentation+xml and mathml- content+xml.
Sounds good to me. Ned
thank you all for this feedback, a working draft of MathML 3 is out since a week or two and the media- types registration appendix is at: http://www.w3.org/TR/MathML3/appendixb.html We shall activate the "new procedure" explained at http://www.w3.org/2002/06/registering-mediatype , so that the request will be filed when we go last-call. In the mean-time, a review would be something nice. paul Le 09-avr.-09 à 17:35, Ned Freed a écrit :
The Expert Reviewer for mime type registrations is Ned Freed, so he has the last say.
That's correct for types registered through the IANA process. Since these types appear to be the standards tree (no vnd. or prs. prefix), that requires IESG processing, which is not my baliwick.
FWIW, in the case of IANA registered types, my job is to apply the criteria spelled out in the relevant registration procedures. AFAIK there isn't a lot of guidance in there as to when it's appropriate to use multiple types versus, say, a single parameterized type. So, absent a clear indication that what's happening are multiple types being defined for the same thing, I would allow all three types to be registered. But as I said, these are standards tree registrations so it isn't my call in any case.
My personal opinion is that either one or three types should be fine, and that probably the WG has the most expertise to decide this, but that you should really consider what others on this list (in particular Mark) said.
Mark's point was, as I recall, the presence of +mathml in the type name. That is indeed somewhat problematic and I would ask it to be changed if I were the reviwer. A -xmathml+xml suffix would be fine though.
Ned
On Wed, Apr 8, 2009 at 11:29 AM, Paul Libbrecht <paul@activemath.org> wrote:
Aside of the question of the "necessity" of specific media-types, the most important question is the "eligibility" of such a request:
Many in our group are convinced that a request for three media-types would be rejected and this only after the last-call draft this summer.
That's not generally the kind of thing that would impede registration. The use of "+mathml" might. Mark.
participants (4)
-
"Martin J. Dürst" -
Mark Baker -
Ned Freed -
Paul Libbrecht