Re: Registration of media typeimage/svg+xml

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=F6rn
> MJD>  H=F6hrmann in another thread saying that RFC 3032 doesn't define fr=
agment
> 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 f=
or XML
> MJD>      media types.  However, a working draft published by W3C, namely=
 "XML
> MJD>      Pointer Language (XPointer)", attempts to define fragment ident=
ifiers
> 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 writte=
n 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 barename=
s) 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/sv=
g+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 i=
ts deprecation of text/xml. I'm working on a way around that, but it depend=
s in turn on resolution of a longstanding issue on HTTPbis.
>
> For another thing, TAG is currently noodling some more on fragments and m=
ay 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 pr=
oposed 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* af=
ter that converted the HTML to plain text, to create the email plain text v=
ersion, 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 becaus=
e 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 go=
ing to mix them up surely.
>
> It says that there is the SVG 1.1 specification, and it says the media ty=
pe 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=FCrst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email protected]