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