First of all, I prefer Martin's text, modulo correcting any technical
errors it may contain.
THat said, the more important point is we cannot have registrations wait on
some future clarification to the confusion surrounding fragment identifiers and
how they should be handled in media type registrations. I cannot, for example,
wait on 3023bis before approving the registrations in other trees that arrive
at a rate of several every week. We've tried that tack before and we know what
happens - people simply stop registrating things and it takes years for
the process to recover.
So if we cannot nail this down I'm OK with moving forward with something
that's understood to be less than perfect. Remember, registrations can
always be revised.
Ned
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ö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).
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 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,
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 written
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 barenames) 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/svg+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 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.
[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
proposed 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* 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,
Just to confirm, fine with me.
> and no to the changing the link from appendix P to the entire spec because
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 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)
>
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp
mailto:duerst(_at_)it(_dot_)aoyama(_dot_)ac(_dot_)jp
_______________________________________________
ietf-types mailing list
ietf-types(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-types