- From: Christopher R. Maden <crm@eps.inso.com>
- Date: Thu, 24 Apr 1997 14:41:17 GMT
- To: w3c-sgml-wg@w3.org
[Jon Bosak] > Method 1: The stylesheet PI Good for demos, but hacky and not very extensible. If we document it, we'll never be able to get rid of it, and there is a far better way. > Method 2: The stylesheet link > > The leading alternative to the PI approach is to use some kind of > specialized link. This has seemed so obvious to everyone that no > one has bothered to propose specific syntax for it. I will leave > this as a challenge for the more imaginative members of the WG. This is definitely my preferred method. > Some questions that will need answering are: > > Does the stylesheet link go in some kind of meta section, like > HEAD in HTML? If so, how is that defined? Nay, no more than any other link needs to. > Is a stylesheet link a normal link with a particular ROLE > attribute? If so, ROLE becomes an enumerated attribute type. Not necessarily. Singling out certain role values doesn't mean that all values need be enumerated, any more than recognition of certain attribute names for linking means that all attribute names must be enumerated. > Is a stylesheet link always a simple link? Sometimes a simple > link and sometimes an extended link? (It's easy to think of good > uses for extended stylesheet links.) Always an extended link? > Some different kind of link entirely? I think that simple and extended links should never be distinguished for applications; otherwise, the power of extended links is reduced. > Method 3: The stylesheet attribute Yuck. A simple link wouldn't be (much) harder than this, anyway. Stylesheet links provide a host of benefits. To address Jon's goals: > 1. Dsssl-o already exists, so while its refinement may be considered > > 2. CSS already exists; it can and will be used with XML documents. Linking allows either to be used, as well as FOSIs, DynaText stylesheets, and Q (which I think is the Grif stylesheet language). (Not that I would recommend use of any proprietary language with XML.) The question does arise as to how to differentiate between DSSSL-o and CSS stylesheets. A separate role for each means that new roles are needed for any new stylesheet language. Additionally, it's clear that if linking more than one stylesheet, a simple link will not suffice. Given the 6 April XML-link draft, I'd recommend something like the following: <!-- styles associates an element with one or more stylesheets --> <!ELEMENT styles (target, style+)> <!-- title's meaning is undefined here --> <!ATTLIST styles xml-link CDATA #FIXED "EXTENDED" role CDATA #FIXED "XML-STYLES" title CDATA #IMPLIED > <!-- target is a pointer to an element --> <!ELEMENT target EMPTY> <!-- href is a pointer to the element to which these styles apply title's meaning is undefined --> <!ATTLIST target xml-link CDATA #FIXED "LOCATOR" role CDATA #FIXED "XML-ELEMENT" href CDATA #REQUIRED title CDATA #IMPLIED > <!-- style is a pointer to a stylesheet --> <!ELEMENT style EMPTY> <!-- href is a pointer to a stylesheet title is the human-readable title of the stylesheet, used for multiple-choice behavior is the MIME type of the stylesheet; defaults to application/dsssl --> <!ATTLIST style xml-link CDATA #FIXED "LOCATOR" role CDATA #FIXED "XML-STYLE" href CDATA #REQUIRED title CDATA #IMPLIED behavior CDATA #IMPLIED > <styles title="Root Styles"> <target href="#ROOT"/> <style href="foo.dsl" title="Foo View" behavior="application/dsssl"/> <style href="foo.css" title="Foo View" behavior="application/css"/> <style href="diff.dsl" title="Different View" behavior="application/dsssl"/> </styles> The first stylesheet referenced should be considered the default, if usable. An application could permit users to switch between stylesheets, perhaps removing stylesheets whose syntax it did not understand. Stylesheets linked with child elements take precedence over those linked with parents. > 3. DSSSL allows a single specification to contain multiple > stylesheets, but CSS does not, so there must be a way to point to > multiple stylesheets that use a single stylesheet language as well > as to multiple stylesheets using different stylesheet languages. I don't see a problem with James Clark's use of foo.dsl#ident to refer to the stylesheet "ident" in the file "foo.dsl" as part of phase 3. > 4. CSS allows for style specifications to be embedded directly in > the start-tags of the elements to which they apply. I have argued > in the past that this will be very common in XML documents generated > from databases, but now I'm not so sure. Do we allow this in XML > documents? If so, how? Yucko. I would just not mention it. Since XML allows definition of one's own document types, nothing will stop users from doing this if they need to, but I don't see a need to encourage it. > 5. I have been informed by someone who watched a discussion of this > take place in the html-wg that there is a requirement for > stylesheets to be associated with specific parts of a document. > (Makes sense when you think about it.) Using the linking specification makes this trivial. The example above can easily accomodate this. > 6. The performance implications of different methods for calling in > and applying stylesheets are beyond my ken, but there surely must be > some. The implementors among us should be careful to consider the > impact of the various approaches on the way that documents will > actually be rendered. I would recommend in the specification that the extended link group associating stylesheets with a given element occur before the element, if it occurs in the same document instance. The linking method meets all of these goals, plus allows a systematic way to associate new stylesheets with others' documents. If I am visually impaired, and the data publisher did not create an audio stylesheet, I can create one myself. I would associate that stylesheet with the document by creating an extended link group in another document; stylesheet creation tools would do the same. This would also allow me to easily share this stylesheet with other members of my community. Thoughts? -Chris -- Christopher R. Maden One Richmond Square DynaText SIT Technical Support Providence, RI 02906 USA Inso Corporation +1.401.421.9550 (voice) Electronic Publishing Solutions +1.401.521.2030 (facsimile)
Received on Thursday, 24 April 1997 10:57:12 UTC