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 Wednesday, 20 July 2005 19:25:45 UTC