- From: Paul Grosso <pgrosso@arbortext.com>
- Date: Wed, 20 Jul 2005 15:25:39 -0400
- To: <public-xml-core-wg@w3.org>
Here is the email from Chris about the stylesheet PI's use of fragment identifiers. Technically, the XML CG hasn't yet passed this on to the XML Core WG, but it seems to make sense to start discussion on it. paul -----Original Message----- From: w3c-xml-cg-request@w3.org On Behalf Of Chris Lilley Sent: Wednesday, 2005 July 20 12:45 To: w3c-xml-cg@w3.org Cc: Hypertext CG Subject: Stylesheet PI etc Hello w3c-xml-cg, The problem under consideration is the interpretation of the type attribute on an HTML lin rel="stylesheet", or type pseudo-attribute on a stylesheet PI, in the case where the URI includes a fragment identifier. <?xml-stylesheet href="A.xhtml#foo" type="text/css" ?> where A.xhtml is <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" > <head> <title>My commonly used style sheets</title> <style id="foo" type="text/css"> p {color: red } </style> <style id="bar" type="text/css"> p {color: blue } </style> </head> <body> <p>I'm just a placeholder.</p> </body> </html> The issue is that the media type of A.xhtml, returned by the server, is application/xhtml+xml. This would on the surface seem to contradict the type attribute. However, application/xhtml is not a stylesheet language and text/css does not define a fragment identifier syntax. I had initially tried to solve this using the concept of primary resource and secondary resource, as defined in AWWW: Two portions of the Architecture of the World Wide Web are crucial to an understanding of this issue. The first is that fragment identifiers are always interpreted in the context of the returned media type [0]: The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution are therefore dependent on the type of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and, effectively, unconstrained. Fragment identifier semantics are orthogonal to URI schemes and thus cannot be redefined by URI scheme specifications. The second is the concept of primary and secondary resources. The following definition of a secondary resource is found in both WebArch [1] and RFC 3986 [2] The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations. A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI. In the case of a stylesheet URI with a fragment identifier, the 'type' attribute can be said to indicate the type of the secondary resource. This is conformant with the TAG finding [3] that the media type returned by a server is authoritative and that metadata or hints on the link (eg, the type attribute on an HTML 'a' element) does not override this. The server authoritatively states the type of the primary resource, allowing the fragment identifier semantics to be determined, and the type of the secondary resource is given by the type attribute or pseudo-attribute. It is also important to note, again from WebArch [4] Any resource can be identified as a secondary resource. It might also be identified using a URI without a fragment identifier, and a resource may be identified as a secondary resource via multiple URIs. Thus, in the case of a link to a stylesheet which does not include a fragment identifier, the type attribute still identifies the secondary resource. In this case however, the secondary resource and the primary resource are the same. The same reasoning can be applied, for example, in the case of a script element which links to, rather than including, the script contents: A.svg <svg xmlns="http://www.w3.org/200/svg xmlns:x=:http://www.w3.org/1999/xlink"/> <script xml:id="foo" type="application/ecmascript"> .... script here ... </script> </svg> B.svg <svg xmlns="http://www.w3.org/200/svg xmlns:x=:http://www.w3.org/1999/xlink"/> <script type="application/ecmascript" x:href="A.svg#foo"/> </svg> This resolution also has the nice property that the type of portions of a mixed namespace compound documents, such as [5] can be given using internet media types. Further discussion showed some problems. A#foo points (in the case of a style element, a script element, etc) to an entire element, not to the content of that element. Use of the type attribute in this way is not consistent with the Internet Media types (MIME) specification. The style element has an attribute that says it is text/css and yet the server is authoritative and the server says the whole thing is text/html. Some people (such as Bert Bos) feel that the stylesheet PI should only ever be used to point to an entire stylesheet (similarly for pointing to an entire script, etc) - perhaps because current HTML browsers will not follow a PI that points to the style element in another document. Steven Pemberton said that @type on <style> is clearly meant to identify the style language, and @type on <a> is clearly meant to represent the media type of the resource (before applying the fragment identifier), but @type on <link rel="stylesheet"> wants to play both roles. Its needed role on <?xml-stylesheet?> however seems to be to identify the style language, not the resource. Al Gilman stated that sometimes the data of interest is an attribute value on the pointed-to element, or even an indirected (tertiary?) resource (such as, what the src attribute on a given XHTML2 element points to) and was unwilling to consider a solution where only the element content was available. This was a requirement from WAI, that the element content and the resource obtained by dereferencing an attribute be seen as alternate contents: Why care? HTML WG has taken pains to let formats expose representation alternatives in a machine-understandable but client-controlled way through a cascade of nested elements each of which has an @src attribute. Like XML to SGML, this is a streamlining of the generic essence of what was the 'object' element heretofore. There has been a pretty consistent demand from the WAI (multiple working groups) for such a client-controlled mechanism for offering representation options (discussed sometimes as equivalent alternatives or conditional content). If the @src -referenced resource of the (outer) #fragment-indicated element were somehow off the table when the client chooses how to present some information, the whole solution would be broken. Meanwhile, the XHTML spec has solved the local issue by adding a new hreftype attribute to the style element as reported here: [6] However I do not see this reflected in the latest XHTML2 draft [7] The XML Stylesheet PI depends normatively on HTML 4, which is not being maintained, and thus any changes to XHTML 2 do not in fact affect the Stylesheet PI which would need therefore to be separately revised. The questions are a) Is the current type attribute authoritative b) Is it conveying the same info as the HTTP Media type of the primary resource c) Are fragments allowed in the URI (note that changes from RFC 2396 to RFC 3986 mean the fragment is now seen as part of the URI d) If fragments are allowed, does a different attribute need to be added to define the type of the secondary resource, or not e) If it is desired to point to attribute content and element content, how should this be done (XPath?) [0] http://www.w3.org/TR/webarch/#media-type-fragid [1] http://www.w3.org/TR/webarch/#fragid [2] http://www.ietf.org/rfc/rfc3986.txt section 3.5 [3] http://www.w3.org/2001/tag/doc/mime-respect.html [4] http://www.w3.org/TR/webarch/#fragid [5] http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/ [6] http://lists.w3.org/Archives/Member/w3c-html-cg/2005AprJun/0033.html [7] http://www.w3.org/TR/xhtml2/mod-styleSheet.html#s_styleSheetmodule -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead
Received on Wednesday, 20 July 2005 19:25:45 UTC