RE: inconsistencies between XSL and XLL

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

Hi Paul,

You said:

I hear you discussing information from the XML Linking Language
(XLink) WD [1] and Associating stylesheets with XML documents PR [2].
While your observation may be a reasonable one to raise, I don't see
that this has anything to do with XSL (as implied by the subject
of this message and the mailing list to which you sent it).  Am I
missing something?

paul

[1] http://www.w3.org/TR/WD-xlink
[2] http://www.w3.org/TR/PR-xml-stylesheet

Reply:
Here is the issue:
I  am making a proposal to colleagues (this mailing list participant and
that includes W3). That the "media" property is to be used to specify the
output format. For example, a XSL engine could be used as a transformation
engine to transform XML into OpenGL or an other XML document into RTF, Tex,
etc... Of course several way could be used to accomplish this goal. But I
restrict my intervention on the xml-stylesheet processing instruction. So,
if I include a processing instruction like this:
<?xml-stylesheet href="myscript.xsl" type="text/xsl" media="screen, HTML?>
<?xml-stylesheet href="myscript.xsl" type="text/xsl" media="print, Tex"?>

I indicate to the rendering engine that this style sheet requires an output
with the same quality level as HTML model or Tex model. If the current
rendering engine do not support such formats, it should degrade to something
it can do. If no "media" property is specified, the document is rendered by
the default rendering engine with a certain premises like for instance that
the media is set by default to "screen" and that the rendering model is what
behind HTML and not yet defined by W3. It is implicitly there behind HTML
and CSS specs but not explicitly defined.

Under certain circumstances, a document may require a certain kind of
environment like CAD rendering (high drawing precision, scale, solid
modeling, etc...) in that case, the media property becomes necessary to
specify that we need a certain format. One day we may have a consortium that
will decide what CAD format is politically correct but until then, we have
to deal with that. So, until then, a document may include that this XML
should be rendered with a de-facto standard (mean here a majority of people
are using it) to render the document. This could be for example DXF which
implies a certain model. Not the format per se, but the model behind this
format (scale definition, naming convention, object relationship,
constraints, etc...). Any DXF compliant engine may do the job (DXF is an
open format that any can implement). I am not here to judge if the fact that
DXF format is there this gives a certain monopoly advantage to AutoDesk.
Because we may also come to the same arguments after a certain time about an
institution and its possible corruption (just look at the Olympic committee
and they are not alone as you know). So, because people call a certain
rendering model DXF, a XML document may contain the media property to
specify that rendering is to be done with the DXF Quality of service or
implicitly following the DXF model. That until a group decide that this no
longer called DXF but something else (the real model name).

When all rendering models will be specified, we won't have to give format
names like DXF or Tex or whatever, but until then, we can use these names.
Also, we already have this kind of model with plug-ins. Plug-ins are here
because of rendering limits of actual W3 specs (of course it takes time to
build a complete world - it is not an easy task). Also, if we do not allow
provision for innovation we will go back to middle ages. So plug-ins provide
either adaptation to the legacy or ways to integrate new formats. This is
what the "media" property can do for XML. But we may agree on a convention
and not let a single manufacturer being AOL, SUN or Microsoft decide for us.

Thus,
The proposal is:
a Stylesheet processing instruction may or may not contain a media property.
By default, the media property is set to "screen, Default" this means that
the document renderer display the document on the screen and with its
default rendering model - to be defined by W3 specs and well specified yet -
this is a work in progress. Thus, if no media property is present, the
default values are used. A browser having no expansion capabilities can
ignore the media property and render with the default value. if it does. 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 explitly mentionned by a general term like "3D"
Where the 3D model is defined somewhere (space model, texture maps models
etc...). This means that a certain decoupling between the style sheet engine
and the rendering model may exist (i.e the style engine generate rendering
instructions instead of writing directly on the screen and thus provide a
better engineered solution). This do not imply that the rendering engine is
provided by a single vendor. Like for DXF plug-ins, Autodesk is not the sole
player. Of course, an intelligent document renderer can know what a DXF
model is and render with the same quality, or find a good approximation. So
then, I can imagine a XSL engine that could render in 3D or have the XSL
engine understand some macros specific to 3D. This until W3 or whatever we
will have in the future, has a good rendering model for that. So Paul the
issue is not about Xlink but about rendering something not very well
grounded yet in the specs and surely not tested in the marketplace.

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



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