"Martin J. Duerst" wrote:
I'm not sure I'm happy with this; defining a minimum that every
+xml type has to support would be very desirable in my eyes.
That's one of the ideas behind the +xml suffix, isn't it.
So how should this minimum look like?
My understanding from Dan was that the cat's already out of the bag; SVG
uses +xml.
However, SVG isn't yet a W3C recommendation. According to
http://www.w3.org/TR/SVG, SVG 1.0 is in CR as of August 2nd. This CR
references a version of draft-murata-xml that used the "-xml" suffix, so
that's what's used;
http://www.w3.org/TR/SVG/intro.html#MIMEType
Also, IANA shows that a MIME media type for SVG has not yet been
registered. I think this means we have an opportunity to guarantee
*something* about fragment identifiers.
Here's some options I've come up with. Each of them has drawbacks, but
hopefully those involved with SVG can weigh that against the future cost
of not having a consistent fragment identifier notation on +xml media
types.
1. leave the SVG MIME media type as-is with "-xml" so it user agents
don't expect the rules of "+xml" to hold. I don't believe that this is
a great loss for SVG because it's an image/ type, not text/ or
application/ about which encoding rules are defined. Or just change it
to image/svg.
2. remove that section (1.2) from the spec (as we did with XHTML 1.0, so
we could add it later).
3. break out and document your subset of XPointer so that
draft-murata-xml can reference it
Any other options? Chris?
MB