Re: [ietf-types] Registration of media typeimage/svg+xml

["Martin J. Dürst" <[e-mail]>]

Hello Chris,

On 2010/11/25 15:53, Chris Lilley wrote:
> On Thursday, November 25, 2010, 7:30:41 AM, Martin wrote:
>
> MJD>  Sorry to pull back yet another time.
>
> Oh, after a decade of not getting registered, I'm getting used to someone bringing up a last minute problem as soon as it looks like we can go ahead.

Really sorry about that.

> MJD>   I just found a comment by Björn
> MJD>  Höhrmann in another thread saying that RFC 3032 doesn't define fragment
> MJD>  identifiers.
>
> I know. But the TAG wants its successor to talk about them (and it does).

I know. I recently had the chance to attended the respective session 
where the TAG discussed this issue.

> You seem to have missed the *** part below:

No, I didn't.

> Fragment Identifiers
>
>          For documents labeled as application/svg+xml, the fragment
>          identifier notation is that for application/xml, as specified
>          in RFC 3023 *** or its successors ***

That would be fine (with me, in any case) if RFC 3023 said something 
definite about this issue. But it just mentions an "attempt".


> MJD>  Upon checking, I found the following:
>
> MJD>  http://tools.ietf.org/html/rfc3023#section-5
>
> MJD>      As of today, no established specifications define identifiers for XML
> MJD>      media types.  However, a working draft published by W3C, namely "XML
> MJD>      Pointer Language (XPointer)", attempts to define fragment identifiers
> MJD>      for text/xml and application/xml.  The current specification for
> MJD>      XPointer is available at http://www.w3.org/TR/xptr.
>
> But that language is no use either,

I agree. I just put it in there so that everybody can see what it says.

> because as you point out
>
> MJD>  On top of that, http://www.w3.org/TR/xptr/ says it's superseeded.
>
> Which I also know, because RFC 3023bis has better language and was written after XPointer was superceeded.

That will be great, once RFC 3023bis will actually be an RFC.

> MJD>  In
> MJD>  this light, the following text from the registration may need
> MJD>  reconsideration:
>
> No, it really doesn't, because it already has some future proofing built in because of "or its successors"

I don't mind "future proofing" if the present is also well defined. But 
I don't think it's very appropriate to use "future proofing" if the 
present isn't well defined.

> plus the fact that I have a fair idea what its successor will say.

I know you are one of the authors, and I trust you to do a good job on 
this, but I also know that things often change.

>   >>>  Fragment Identifiers
>
>   >>>  For documents labeled as application/svg+xml, the fragment
>   >>>  identifier notation is that for application/xml, as specified
>   >>>  in RFC 3023 or its successors, plus the SVG-specific SVG Views
>   >>>  syntax described in the SVG specification.
>
> MJD>  What about:
>
>
> MJD>  Fragment Identifiers
>
> MJD>  For documents labeled as application/svg+xml, the fragment
> MJD>  identifier notation follows the XML Pointer Language (XPointer)
> MJD>  Framework (see http://www.w3.org/TR/xptr-framework/). Fragment
> MJD>  identifiers are either Shorthand Pointers (formerly called barenames) or
> MJD>  SVG view specifications.
>
> No, because that misses out the XPonter registry for example.

I was under the impression that the only fragment syntaxes usable in SVG 
would be 'barenames' and the view syntax. So I thought that the XPointer 
registry was essentially irrelevant. If that's wrong, feel free to tweak 
the above text.

However, if we actually had different ideas of what would be allowed as 
SVG fragment identifiers, then this might show that pointing to a text 
like "attempts to define fragment identifiers" isn't clear enough.

> MJD>  For details, please see Section 17.3.2 of the
> MJD>  SVG specification
> MJD>  (http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers).
>
>
> MJD>  or some such. I hope that RFC 3023bis can be completed soon,
>
> Martin, how can I put this politely.
>
> No. NO!
>
> No, we are not waiting for 3023bis to be done before registering image/svg+xml.

Sorry, but if you had read the whole sentence I wrote (see below for the 
rest) before writing this, you would have understood that you don't have 
to disagree with me, because I already agree with you: Let's register 
image/svg+xml without waiting for RFC 3023bis to be completed.

> For one thing, 3023bis was sort of ready when there was an objection to its deprecation of text/xml. I'm working on a way around that, but it depends in turn on resolution of a longstanding issue on HTTPbis.
>
> For another thing, TAG is currently noodling some more on fragments and may want some 3023bis changes to special case RDF fragment identifiers.

[My understanding is that they already made their mind up on this, and 
set the authors (including you) an email about this, but that there may 
be an issue left with fragment identifiers and RDF*a*.]

> So, I am much more comfortable with the current wording than with your proposed change.

The current wording points to an "attemt" and some future spec that we 
don't know when it will be done. I'm not sure what makes you comfortable 
about that.

My wording was an attempt to remove these dependencies to make it clear 
what can actually be used as a fragment identifier. If I got something 
wrong, I don't have any problem with my proposal being fixed.

> MJD>  and make
> MJD>  this easier, but I hope we don't need to wait for this to complete the
> MJD>  image/svg+xml registration.
>
> Exactly. So - no.
>
> MJD>  This also brings me to another nit. The registration currently says:
>
>   >>>  Published specification:
>
>   >>>  This media type registration is extracted from Appendix P of the
>   >>>  SVG 1.1 specification.
>   >>>  http://www.w3.org/TR/SVG/mimereg.html
>
> MJD>  First, we made some tweaks,
>
> Martin, I have made the tweaks *to the editors draft* and it will show up under /TR next time it gets published, okay?

Ah, okay, then that's fine with me.

> In fact, to be sure, I made the tweaks to the editors draft and *then* after that converted the HTML to plain text, to create the email plain text version, to be sure they were identical.
>
> MJD>  and second, the published specification is
> MJD>  all of SVG 1.1, not just the mimereg part,
>
> Obviously
>
> MJD>  as far as I understand. So
> MJD>  what about something like:
>
>
> MJD>  Published specification:
>
> MJD>  This media type registration is an extracted and slightly adapted
> MJD>  version of Appendix P of the SVG 1.1 specification
> MJD>  (http://www.w3.org/TR/SVG11/).
>
> No to the 'slightly adapted' for reasons given above,

Just to confirm, fine with me.

> and no to the changing the link from appendix P to the entire spec because that is what the text says.

It is not clear whether the parenthesis is a clarification to "Appendix 
P of the SVG 1.1 specification" or "the SVG 1.1 specification". I was 
expecting the later, also because that would be in line with the title 
of the section (Publish Specification must be SVG 1.1, not only appendix P).

Regards,   Martin.

> The registration is appendix P and the spec is the spec, and no-one is going to mix them up surely.
>
> It says that there is the SVG 1.1 specification, and it says the media type registration is extracted from appendix P of it.
>
> Alexey, Keith, I request that we move ahead with the text that I submited earlier, on Wednesday, 24 November 2010, 23:36:35  (Wed, 24 Nov 2010 23:36:35 +0100)
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[e-mail]