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

[Chris Lilley <[e-mail]>]

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.

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). You seem to have missed the *** part below:

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 ***


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, 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.

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" plus the fact that I have a fair idea what its successor will say.

 >>> 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.

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.

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.

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


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?

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, and no to the changing the link from appendix P to the entire spec because that is what the text says. 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)

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups