RE: About the style processing instruction

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

Hi Oren

-------------------
you said:
[....]
So I revised my understanding; I took it to mean that the XSL engine should
create <fo:*> elements as usual and then translate the <fo:*> elements into
the specified type - and possibly display the document using the appropriate
back-end for this type - if it can; and do the best it can otherwise.
Shouldn't such decisions be left to the user which invoked the XSL
processor? After all, he knows which back-ends he has (Word, Adobe Acrobat
or a DVI viewer) and which one he is interested in... And the <fo:*>
document is identical in all cases. Or am I missing something?

NO Oren you are not missing something you got it right. However, you can
have this operation done automatically. An intelligent browser may know that
you have a Tex backend that can render FOs as asked by the PI. If the
browser is even more better, it can also let the user set preferences like
saying "I always want my FOs displayed with that ... backend" (of course in
a more user friendly way). This choice would overwrite the document creator
choice. So, the document creator could ask for a certain backend to render
FOs (maybe because a certain backend offer better rendering quality for his
kind of document). The user can overwrite that by specifying that everything
is displayed by only a certain type of backend and finally this choice could
be also imposed by browser limitation. The best situation would be that a
browser can render with a diversity of backbends, this until we have a
common spec for rendering language or rendering engine.
-------------------

------------------
I said:
"The media property can specify the output device (print, screen etc...) and
the
rendering model. The rendering model could be expressed by a format like DXF
and thus be implicit or explicitly mentioned by a general term like "3D"
..."

you replied:
And I'm totally lost. How can the media attribute specify the rendering
model? This is fixed by the <fo:*> language. Do you mean that the <fo:*>
language can be extended with "some macros specific to 3D" so that it would
be possible to use the same output document for print, screen and _3D_? And
similarly for any other model we might come up with - e.g., visualization
graphs, sounds, force-feedback, ...? Just reconciling the 2D <fo:*> model
with a 3D model would be one hell of an achievement. Shouldn't this be
better left to a different stylesheet per rendering model "family" (2D, 3D,
...) - presuming an XML language is defined for each (e.g. VRML for 3D)?

Reply:
My first idea was to use a new parameter called "format", then Chris
intervention, except for fundamental philosophical divergences pinpointed
some good points and let met check again the specs and use a property called
media that can already be expanded with new parameter. Actually, this
property let you specify the media type like (screen, print, etc...). The
specs say that you can have other parameters added to the one already
specified as long as they are separated with "," like for instance
media="screen,3D". This is why I used this property to specify how the FOs
are rendered like for example media="screen,Tex".

You are right about the difficulties to reconciliate 2D and 3D, etc...We
even have difficulties to reconciliate the CSS and XSL FOs. However the
style Processing instruction shouldn't be solely reserved to XSL but a
general capability for style sheets. For example, our own implementation
allows you to set three different kind of style sheet for a XML document,
like in the following example:
<?xml-stylesheet href="mystyle.css" type="text/css" media="screen,
default"?> <-------- CSS default rendering engine
<?xml-stylesheet href="mystyle.xsl" type="text/xsl" media="screen, default"
?> <-------- XSL default rendering engine
<?xml-stylesheet href="mystyle.dsl" type="text/dsssl" media="screen, TEX" ?>
<------------ DSSSL Tex rendering engine
You can also imagine that other style engine could also use the PI. As you
know two other well known transformation languages could be used to
transform XML documents into displayable entities: omnimark and balise. You
could also have script languages like PERL, javascript or Python. Within the
boundaries a corporation (an intranet) or a group (a community) they can use
such language to render their document. We may argue about interoperability
but it remains that these people could choose for good reasons to use such
language for their own community. The point is: The PI definition should be
versatile enough to provide capacity to support multiple style engine. For
example, we are doing a new implementation to support the following PI:
<?xml-stylesheet href=mystyle.omk" type="application/x-omnimark"
media="screen, default" ?> <-------- omnimark language for the omnimark
community. Again, I won't argue about interoperability but this is for the
omnimark community. If they want inter-operability they would probably go
for CSS. but that is not the point. Thus, some style engines have the
capability to convert FOs into other languages or rendering processing
instructions, the proposal target this.

About your suggestion for different style sheet for 3D etc... I agree
because of our present state of the art. However, the style processing
instruction has a broader scope than for XSL or CSS and should provide
provisions for this. This is why I am making this intervention. It is only
focused on the PI and not on the style language choice. Only how we
standardize the PI for multiple style languages and different XML usages.
According to the present state of the art, in the case of 3D, I may have two
different kind of style sheet like:
<?xml-stylesheet href="myscript.???" type="text/???" media="screen, OpenGL,
Glasses"?> the XML document is to be rendered with a 3D style sheet, use
OpenGL to render 3D objects and need 3D glasses for optimal experience.
<?xml-stylesheet href="myscript.???" type="text/????" media="screen, DXF" ?>
the XML document is to be rendered with a 3D style language, uses the 3D DXF
rendering language (or similar rendering model). Note: the style engine may
or may not output DXF instructions. It may just support the same model and
directly render on the screen the result. An other style engine may just
output DXF data and let the browser load the DXF renderer. Even if this
schema is not the best, it allows browsers to adapt (with pug-ins mechanism
or otherwise) to diversity until we have mastered this diversity and stated
a common spec (brrrr this reminds me the Apple ad some years ago about big
brother ;-)

thanx for your comments Oren.
regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com



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