[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ietf-types] Registration of media typeimage/svg+xml
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
I know. But the TAG wants its successor to talk about them (and it does). You seem to have missed the *** part below:
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> 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> this light, the following text from the registration may need
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> or some such. I hope that RFC 3023bis can be completed soon,
Martin, how can I put this politely.
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.
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,
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
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