Subject: XML fragment identifier interpretation
From: [email-masked] (Henry S. Thompson)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], Richard Tobin <[email-masked]>
Date: Thu, 24 Jun 2010 15:06:18 +0100
List-Id: <ietf-xml-mime.imc.org>

Consider the following URI:

  http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.xml#element-key

In Firefox 3.6pre, IE8, Chrome 5 and Opera 10, it just works.

But there is _no_ justification for this, in 3023 or 3023bis.  Why?
Because there is no ID with value 'element-key' in the XML document
identified by the above URI.  It exists _only_ in the output of the
XSLT stylesheet named in an xml-stylesheet processing instruction
which appears therein.

Or so it seems to me.

I think we need to add this to the use cases on the table as we
consider the TAG's request [1] to think again about generic processing
and frag-ids.  I'm tempted to say that we need to find a way to allow
application-specific frag-id semantics to co-exist with generic
semantics.

One subsidiary question -- is this or is this not a "same-document
reference" [2]?  Or, to put it another way, where if anywhere do we
find a definitive answer to the question of what the base URI is of
the _output_ of an XSLT stylesheet applied in these circumstances?

ht

[1] http://lists.w3.org/Archives/Public/www-tag/2010Jun/0125.html
[2] http://www.apps.ietf.org/rfc/rfc3986.html#sec-4.4
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Date: Fri, 18 Jun 2010 19:40:20 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: [email-masked] (Henry S. Thompson)
CC: [email-masked], [email-masked]
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

On Friday, June 18, 2010, 5:50:56 PM, Henry wrote:

HST>    Fragment Identifiers

Good point, fragment identifiers.

HST>    For documents labeled as application/svg+xml, the fragment identifier
HST>    notation is exactly that for application/xml, as specified in [RFC
HST>    3023] or its successors.

Except that isn't correct. There is also the SVG view syntax, described at
http://dev.w3.org/SVG/profiles/1.1F2/publish/linking.html#LinksIntoSVG

-- 
 Chris Lilley                    mailto:[email-masked]
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

To: Chris Lilley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Registration of media typeimage/svg+xml
From: [email-masked] (Henry S. Thompson)
Date: Fri, 18 Jun 2010 16:50:56 +0100
Sender: [email-masked]

Suggest you add

   Fragment Identifiers

   For documents labeled as application/svg+xml, the fragment identifier
   notation is exactly that for application/xml, as specified in [RFC
   3023] or its successors.

ht
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Cc: [email-masked], [email-masked]
From: Paul Libbrecht <[email-masked]>
To: Chris Lilley <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Date: Fri, 18 Jun 2010 14:17:03 +0200
Sender: [email-masked]

--Apple-Mail-7-55996643
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

Le 18-juin-10 =E0 12:55, Chris Lilley a =E9crit :
> PL> Could I suggest to add in this registration clipboard format =20
> names as
> PL> part of the additional information so that applications use them
> PL> consistently?
> Happy do do so - could you point to documentation on this so I can =20
> read up?

There's no official place that I know of.

For UTIs, URLs have been a bit changing at Apple, the Wikipedia page =20
seems the most faithful:
	http://en.wikipedia.org/wiki/Uniform_Type_Identifier
and a page at Apple is:
	=
http://developer.apple.com/mac/library/documentation/FileManagement/Concep=
tual/understanding_utis/understand_utis_intro/understand_utis_intro.html

For Windows the only pages I know of are:
	.NET:	=
http://msdn2.microsoft.com/en-us/library/system.windows.dataformats.aspx
	C++        =
http://msdn2.microsoft.com/en-us/library/ms632538.aspx

I've been vaguely trying to list these at my page: =
http://eds.activemath.org/en/node/161

> Do they require separate registration with some other authority, or =20=

> is it sufficient to note them here?

 =46rom the discussion within the W3C Math Working Group members, it =20
appears that there's no registration methods anymore (people from =20
MicroSoft, Design Science, and MapleSoft among others).

One thing I learned the hard way (there was a draft with that error) =20
is that dashes (the minus sign "-") is not allowed in MS clipboard =20
flavor names. Another is that lack of specification gives a broad =20
amount of fancy attempts by just about any implementor.

The pages of the platform makers describe how applications register =20
their clipboard types when running or in the application descriptors.

As far as I know there's no other thing to do than write this in a =20
spec expected to be read by implementors.

> PL> I would suggest the following for uncompressed svg as a first
> PL> approximation, but maybe there are existing attempts already?
>
> PL> - Windows: "SVG Image"
> PL> - MacOSX Uniform Type Identifier: org.w3c.svg conforms to =20
> public.image
> PL> and to public.xml
>
> PL> I am doubting that the 4-letter codes are still in use but I may =20=

> be
> PL> wrong.
>
> Yes, the old MacOS 4-letter codes are mainly historical at this =20
> point, but Apple did allocate them for us (back in 1998) and RFC =20
> 4288 (from Dec 2005) seems to ask for them if they exist, so they =20
> were included.

Perfect then.

paul=

--Apple-Mail-7-55996643
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-7-55996643--

Date: Fri, 18 Jun 2010 13:46:29 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Mark Baker <[email-masked]>
CC: [email-masked], [email-masked]
Subject: re: Registration of media type image/svg+xml
Sender: [email-masked]

Hello Mark,

I have just sent a registration request for image/svg+xml to ietf-types

http://www.alvestrand.no/pipermail/ietf-types/2010-June/002360.html

Looking back in the archives I see an old message from you (2005!)
which I don't recall answering.

http://www.alvestrand.no/pipermail/ietf-types/2005-December/000903.html

Some of the points no longer apply to the new registration, some are
addressed. I wanted to close the loop with you on that anyway, so that
if any of the items you mentioned in 2005 are not addressed to your
satisfaction in the new registration, we can get them fixed.

> On 12/7/05, Chris Lilley <chris at w3.org> wrote:
>>
>>    Optional parameters:
>>           None
>>
>>           The encoding of an SVG document shall be determined by the
>>           XML encoding declaration. This has identical semantics to the
>>           application/xml media type in the case where the charset
>>           parameter is omitted, as specified in RFC3023 sections
>>           8.9, 8.10 and 8.11.
> 
> Can I assume this section above was supposed to be a replacement for
> the encoding section below?

For the new registration, that text no longer appears.

To answer your question though: no, its one of those unfortunate
terminology issues where different terms are used by different
communities. What XML calls the 'encoding' or 'character encoding' is
what IETF calls the 'charset'. So the section was in the right place
and was explaining the lack of a charset parameter.

However, the new registration has the optional charset parameter so no
longer needs the explanatory prose.

>>    Security considerations:

>>           SVG documents may be transmitted in compressed form using
>>           gzip compression. For systems which employ MIME-like
>>           mechanisms, such as HTTP, this is indicated by the
>>           Content-Transfer-Encoding header; for systems which do not,
>>           such as direct filesystem access, this is indicated by the
>>           filename extension and by the Macintosh File Type Codes. In
>>           addition, gzip compressed content is readily recognised by
>>           the initial byte sequence as described in RFC1952 section
>>           2.3.1.
> 
> I don't see how that's a security issue.  Seems more an encoding one to me.

I agree it could be described either way, but there have been concerns
in the past about triggering compression libraries and potential
security concerns due to fixed-length zlib buffers so on balance, we
decided to leave that text in there.

A secondary reason to mention it was that a few implementations accept
uncompressed svg, but fail with compressed svg, or only allow
compressed svg when served over http and not from local disk. So it
seemed worth mentioning the various ways that compressed svg might be
labelled or detected.

If you strongly disagree though, and no-one else speaks up in favour
of this being  worth mentioning in the security section, we are happy
to take it out or move it to the encoding section.

Should the initial byte sequence of gzipped svg be mentioned under
magic numbers? It only shows that the content is gzipped, not that it
is svg, so we did not add it there.

> On the topic of compression though, I had heard a while ago (back in
> the "image/svg-xml" days) that compressed SVG is sometimes sent as
> image/svg+xml.  Is that still (assuming it was ever) the case?

Yes, it is the case. The same media type is used for svg regardless of
whether it is compressed or not. For HTTP, other labelling is used to
indicate the compression.

>  The
> spec seems to make it clear that SVG is compressed via HTTP
> compression.

Yes.

>>    Published specification:
>>           This media type registration is extracted from Appendix M of
>>           the SVG 1.2 Tiny specification.
>>           http://www.w3.org/TR/SVGMobile12
> 
> There was no "Applications which used this media type" section.  I
> think it would be useful to say that there are numerous
> implementations which currently support this media type.

This has been added to the current registration; please check that the
language is satisfactory.

> Also, you might want to mention - probably in "interoperability" -
> that this same media type was also prescribed for use in the SVG 1.0
> and 1.1 specs.  And if there are any backward compatibility issues
> between 1.2 and those, you might want to say something about that.

The current registration is in the context of SVG 1.1, while the old
one was for SVG Tiny 1.2

SVG 1.1 obsoletes SVG 1.0 (but SVG 1.0 did use the same media type)

The same media type is used for SVG Tiny 1.1, SVG Basic 1.1, and SVG
Tiny 1.2. We would be happy to note this in the registration, although
the defining specification covers the relationship in much more
detail.

-- 
 Chris Lilley                    mailto:[email-masked]
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Date: Fri, 18 Jun 2010 12:55:07 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Paul Libbrecht <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Registration of media typeimage/svg+xml
Sender: [email-masked]

On Thursday, June 17, 2010, 9:09:32 PM, Paul wrote:

PL> Dear Chris,

PL> Could I suggest to add in this registration clipboard format names as
PL> part of the additional information so that applications use them  
PL> consistently?

Happy do do so - could you point to documentation on this so I can read up?

Do they require separate registration with some other authority, or is it sufficient to note them here?

PL> I would suggest the following for uncompressed svg as a first  
PL> approximation, but maybe there are existing attempts already?

PL> - Windows: "SVG Image"
PL> - MacOSX Uniform Type Identifier: org.w3c.svg conforms to public.image
PL> and to public.xml

PL> I am doubting that the 4-letter codes are still in use but I may be  
PL> wrong.

Yes, the old MacOS 4-letter codes are mainly historical at this point, but Apple did allocate them for us (back in 1998) and RFC 4288 (from Dec 2005) seems to ask for them if they exist, so they were included.

PL> paul

>>   Additional information:

>>        Magic number(s):

>>        File extension(s):
>>                svg, svgz (if gzip-compressed)

>>        Macintosh file type code(s):
>>                "svg " (all lowercase, with a space character as the
>>                fourth letter), "svgz" (all lowercase, if
>>                gzip-compressed).

-- 
 Chris Lilley                    mailto:[email-masked]
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Cc: [email-masked], [email-masked]
From: Paul Libbrecht <[email-masked]>
To: Chris Lilley <[email-masked]>
Subject: Re: Registration of media typeimage/svg+xml
Date: Thu, 17 Jun 2010 21:09:32 +0200
Sender: [email-masked]

--Apple-Mail-19--5651060
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Dear Chris,

Could I suggest to add in this registration clipboard format names as  
part of the additional information so that applications use them  
consistently?

I would suggest the following for uncompressed svg as a first  
approximation, but maybe there are existing attempts already?

- Windows: "SVG Image"
- MacOSX Uniform Type Identifier: org.w3c.svg conforms to public.image  
and to public.xml

I am doubting that the 4-letter codes are still in use but I may be  
wrong.

paul

>   Additional information:
>
>        Magic number(s):
>
>        File extension(s):
>                svg, svgz (if gzip-compressed)
>
>        Macintosh file type code(s):
>                "svg " (all lowercase, with a space character as the
>                fourth letter), "svgz" (all lowercase, if
>                gzip-compressed).
>

--Apple-Mail-19--5651060
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-19--5651060--

Date: Thu, 17 Jun 2010 16:26:24 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: [email-masked]
CC: [email-masked]
Subject: Registration of media typeimage/svg+xml
Sender: [email-masked]

   Type name:
          image

   Subtype name:
          svg+xml

   Required parameters:
          None.

   Optional parameters:
          charset

          Same as application/xml media type, as specified in
          RFC3023 or it's successor.

   Encoding considerations:
          Same as for application/xml. See RFC3023, section 3.2.

   Security considerations:
          As with other XML types and as noted in RFC3023 section
          10, repeated expansion of maliciously constructed XML
          entities can be used to consume large amounts of memory,
          which may cause XML processors in constrained environments to
          fail.

          SVG documents may be transmitted in compressed form using
          gzip compression. For systems which employ MIME-like
          mechanisms, such as HTTP, this is indicated by the
          Content-Transfer-Encoding header; for systems which do not,
          such as direct filesystem access, this is indicated by the
          filename extension and by the Macintosh File Type Codes. In
          addition, gzip compressed content is readily recognized by
          the initial byte sequence as described in RFC1952
          section 2.3.1.

          Several SVG elements may cause arbitrary URIs to be
          referenced. In this case, the security issues of
          RFC3986, section 7, should be considered.

          In common with HTML, SVG documents may reference external
          media such as images, audio, video, style sheets, and
          scripting languages. Scripting languages are executable
          content. In this case, the security considerations in the
          Media Type registrations for those formats shall apply.

          In addition, because of the extensibility features for SVG
          and of XML in general, it is possible that "image/svg+xml"
          may describe content that has security implications beyond
          those described here. However, if the processor follows only
          the normative semantics of this specification, this content
          will be outside the SVG namespace and shall be ignored. Only
          in the case where the processor recognizes and processes the
          additional content, or where further processing of that
          content is dispatched to other processors, would security
          issues potentially arise. And in that case, they would fall
          outside the domain of this registration document.

   Interoperability considerations:
          This specification describes processing semantics that
          dictate behavior that must be followed when dealing with,
          among other things, unrecognized elements and attributes,
          both in the SVG namespace and in other namespaces.

          Because SVG is extensible, conformant "image/svg+xml"
          processors must expect that content received is well-formed
          XML, but it cannot be guaranteed that the content is valid to
          a particular DTD or Schema or that the processor will
          recognize all of the elements and attributes in the document.

          SVG has a published Test Suite and associated implementation
          report showing which implementations passed which tests at
          the time of the report. This information is periodically
          updated as new tests are added or as implementations improve.

   Published specification:
          This media type registration is extracted from Appendix P of
          the SVG 1.1 specification.

     http://dev.w3.org/SVG/profiles/1.1F2/publish/mimereg.html
     http://dev.w3.org/SVG/profiles/1.1F2/publish/index.html

Applications that use this media type:
          SVG is used by Web browsers, often in conjunction with HTML;
          by mobile phones and digital cameras, as a format for
          interchange of graphical assets in desk top publishing, for
          industrial process visualization, display signage, and many
          other applications which require scalable static or
          interactive graphical capability.

   Additional information:

        Magic number(s):

        File extension(s):
                svg, svgz (if gzip-compressed)

        Macintosh file type code(s):
                "svg " (all lowercase, with a space character as the
                fourth letter), "svgz" (all lowercase, if
                gzip-compressed).

   Person & email address to contact for further information:
          Chris Lilley, Doug Schepers ([email-masked]).

   Intended usage:
          COMMON

   Restrictions on usage:
          None

   Author:
          The SVG specification is a work product of the World Wide Web
          Consortium's SVG Working Group.

   Change controller:
          The W3C has change control over this specification.

  

-- 
 Chris Lilley                    mailto:[email-masked]
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG