RE: About the style processing instruction

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

Hi,

The following text is based on the actual proposal on how to link a style
sheet with a XML document.( http://www.w3.org/TR/PR-xml-stylesheet - January
14 1999). It describes a usage scenario in the context of a browser
implementation. This is only one scenario among all the  possible scenarios.

<scenario>
The user browse to a XML document. This document has several style sheets
attached to and contains several processing instructions targeted to
different style engines.
</scenario>

<Goal>
The browser has an implicit default operation which is "display document in
2D" but also allows other rendering options to be selected with a context
menu. Each rendering option should be specified in styles sheets, and the
browser makes the association between a rendering operation and a
corresponding style.
</goal>

<example>
the XML document has the following prologue (this is a fragment of it and
not the complete prologue):
<?xml-stylesheet href="/style/screen2D.xsl" type="text/xsl" media="screen,
2D"?>
<?xml-stylesheet href="/style/screen3D.xsl" type="text/xsl" media="screen,
3D"?>
<?xml-stylesheet href="/style/print.xsl" type="text/xsl" media="print,tex"?>
<?xml-stylesheet href="/style/screen.css" type="text/xsl" media="screen"?>
<?xml-stylesheet href="/style/print.css" type="text/css" media="print"?>
<?xml-stylesheet href="/style/screen.dsl" type="text/dsssl" media="screen"?>
<?xml-stylesheet href="/style/print.dsl" type="text/dsssl"
media="print,tex"?>

The document author wants that the document could be rendered with diverse
rendering processor. In this example, the author stores all style documents
in the Style context (I do not say directory mainly because we may use a
WebDav server). Two different style documents are provided for each style
language (screen and print), for xsl, a third one is specified for screen
rendering in 3D. Three different style languages are referred from this
document: CSS, XSL and DSSSL. The author mentioned that a Tex print engine
would be required if possible.
</example>

<implementation - A>
The browser is a XML only browser and can process XSL style sheets. It
decodes all "xml-stylesheet" processing instructions, check required
capacity from each style sheet PI, and set its own internal state in
accordance to these requirements (i.e. only consider style sheets with
type="text/xsl"). Then, the browser build a context menu for each "media"
specification. Thus the option "display 3D" is associated to the 3D media
style sheet and the "display 2D" option to the 2D style sheet. This option
is a toggle. When in 3D, it displays "display 2D" and when in 2D it displays
"display 3D". The option "print" is associated to the print style sheet. By
default, the browser is set to "display 2D" by the user. <important>The
browser used the media property to set its context menu</important>. Because
of bandwidth limitations, only the 2D style sheet is downloaded and the
document rendered in 2D. If the user select "display 3D", the 3D style sheet
is downloaded and the document rendered accordingly. If the user select
"print" the print style sheet is downloaded and the document printed with
its own print formatting engine because it does not support the tex format.
Before doing the last operation it notified the used of the author's
requirement for a tex engine, offered a way to download a tex engine or to
use the default browser print engine.
</implementation - A>

<implementation - B>
The browser is a SGML/XML browser and can process only DSSSL style sheets.
As above, all PI are processed and only those with type="text/dsssl" are
considered by the browser. All other operations are similar to the example
above except that in the example, the SGML/XML browser do not have a 3D
screen style.
</implementation - B>

<implementation - c>
A more sophisticated browser can process XML and SGML documents with either
CSS, XSL or DSSSL style engines and support 2D and 3D. The browser can use
different algorithm to select the right style but, in this case, used the
user as an arbitrator and pick the user preferred style. Off course, as a
good citizen, the browser came with a default preference that the user can
change to his convenience.
</implementation - c>

<Conclusion>
Hope this scenario could bring some lights because we have to implement
concrete stuff in a) Microsoft browser either as a complement to what is
already offered, or as a replacement. b) in Mozilla (I do not forget other
products like Opera).

<Issues>
Actually, the media property can be set accordingly to the specs to "print",
"screen", "aural" and some other values. A note is provided for expansion
and is left to implementers interpretation. For instance, there is mention
of 3D value but there is no consensus on which processing instructions do we
use (VRML?, Chrome? either based on actual group standards or de-factor
market based standards). For 3D, Which formatting object do I use? Wold it
be preferrable to transform HTML and VRML in XML standards (not a big job).
Why is this not already done. Is there an issue not publicly published that
prevent the publication of a HTML specs explicitely stating its XML
compliance? Having a HTML or VRML compliant spec would, of course, imply
that we can use these objects as formatting objects in XSL, maybe having to
relate these object to their respective name spaces. The paragraph 2.2 Notes
opens the door with an example of the inclusion of HTML and thus to VRML,
but do not state the boundaries. No provisions are stated in the the
possibility of a new "media" value for a particular rendering format like
CGM, RTF or Tex. Browsers would need to either consider the added value
(i.e. tex, rtf, CGM, etc.) or simply ignore it in the media value parsing
process. In fact, a note in the media property definition states that
browsers should parse the expression and either use or ignore the require
capability. this is probably the best solution.
</issues>

However, from the examples above, to define style sheets association to XML
documents with PI can help browsers create rendering selection device as,
for example, a context menu as soon as the XML document is decoded and
downloaded. Other style sheets could be downloaded just in time as required.
In case, where several PI are present in the document and targeted for
different style engines, the browser has to resolve the style engine choice
with its own resolution mechanism. The advantages for the author to include
style sheets PI in the XML document is that the document can potentially be
processed with more browsers types each having different capabilities. For
instance, there is a high probability that the next Mozilla version will not
have a XSL processing engine but be equipped with a good CSS engine. An
author wanting that the document be processed either by IE and Mozilla may
include Processing instructions for XSL (decoded by IE) and CSS (decoded by
Mozilla). We don't know yet from market experience (specs are still moving
targets)if XSL offers more possibilities than CSS but its more elaborate
instruction set permit to think so (and some early experiments allows us to
think so). Thus, a XSL capable browser (ex: IE) may  select XSL as the
default possible style engine (more rendering capabilities). A browser
having only CSS (ex: Mozilla) may not have the choice but use CSS (which
still offers good rendering possibilities). If an active DSSSL group is
formed and the DSSSL specs improved, a more elaborate browser may also
consider this style alternative.

It remains, that the inclusion of several Processing instructions in the
XML/SGML document provides possible adaptability and choice to authors and
flexibility of selection and processing to browsers.
</conclusion>

Regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list