Subject: RE: About the style processing instruction From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Sun, 31 Jan 1999 10:18:14 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Fw: About the style processing inst, Oren Ben-Kiki | Thread | Re: About the style processing inst, Matthieu DELAHAYE |
Re: inconsistencies between XSL and, Chris Lilley | Date | RE: inconsistencies between XSL and, Didier PH Martin |
Month |