Re: 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 b=
ringing up a last minute problem as soon as it looks like we can go ahead.

MJD>  I just found a comment by Bj=F6rn =

MJD> H=F6hrmann in another thread saying that RFC 3032 doesn't define fragm=
ent
MJD> identifiers. =


I know. But the TAG wants its successor to talk about them (and it does). Y=
ou 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 "X=
ML
MJD>     Pointer Language (XPointer)", attempts to define fragment identifi=
ers
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 prop=
osed 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 u=
nder /TR next time it gets published, okay?

In fact, to be sure, I made the tweaks to the editors draft and *then* afte=
r that converted the HTML to plain text, to create the email plain text ver=
sion, 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 changin=
g 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 e=
arlier, on Wednesday, 24 November 2010, 23:36:35  (Wed, 24 Nov 2010 23:36:3=
5 +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