RE: Stylesheet PI etc

By the way, a discussion (including members of the 
HTML CG and XML CG) of this thread is occurring; see 
http://lists.w3.org/Archives/Member/w3c-xml-cg/2005Jul/
starting at message 0015 (July 20th).

paul

> -----Original Message-----
> From: public-xml-core-wg-request@w3.org 
> [mailto:public-xml-core-wg-request@w3.org] On Behalf Of Paul Grosso
> Sent: Wednesday, 2005 July 20 14:26
> To: public-xml-core-wg@w3.org
> Subject: FW: Stylesheet PI etc
> 
> 
> 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 Thursday, 21 July 2005 16:26:13 UTC