RE: Announcement

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

Hi Chris,

Thread 1 ------------------
Didier PH Martin wrote:

> - Full XML support. If a document includes a style sheet PI in the XML
> document will be associated to the correct style sheet for the following
> styles: CSS, XSL and DSSSL.
Great

> If you have IE 5.x beta installed, the Microsoft
> CSS and XSL engine will process the document and display it in the
browser.

Chris replied:
This implies that it uses the earlier form of the pi - xml:stylesheet.
The later form is xml-stylesheet (which is what NGlayout uses, for
example).Newer code releases if IE will presumably be migrating to the
latest syntax.

Reply------------------
Yes Microsoft IE 5.x was released before the new style sheet recommendation
so it uses the earlier form of PI. I guess too that the next release will
respect the new one. Probably both form as we do.


Thread 2 -----------

Didier wrote:
> Jade engine will process the XML document with DSSSL styles. We followed
the
> latest W3 recommendations about style sheets PI but got to add a new
> property because, the actual spec is limited to HTML display

Chris replied:
erm .. no, it isn't restricted to HTML; in fact it says nothing about
HTML at all.

Reply ------------
If it is not restricted to html you then have to notify the XSL engine with
an other way than the PI, for example a command line (and a command line is
user friendly doesn't it? :-) So, the actual scheme for sytlesheet PI is
that the output is not selected and therefore implicitly stated to html if I
look at the actual implementations. Do you know one XSL processor who does
output in rtf or tex?


Didier wrote:
> and do not
> include other kind of renderer.

Chris reply:
Ah I see, you mean the intermediate stage which some implementations use
(to push off the actual formatting to yet another step in the process)

Reply ----------
Exactly this is done anyway either implicitly and you don't choose the
output or explicitly and you choose the output but anyway, from the style
processor point of view it is the same process: you generate display/print
instructions.


Didier wrote:
> We added the "format" property so, for DSSSL
> styles you can select from the PI the output format.

Chris reply:
Have you suggested this to the XSL group? One problem with it is that it
becomes impossible to write a stylesheet link that is generic; that does
not make assumptions about the style sheet processor. Your three
examples below are clearly targetted at Jade. Suppose someone has a
different processor? Suppose there are three or four different
processors - does the document author need to write multiple
stylesheets, one for each processor?

Reply-------
Not if the processor is well done. Normally, and this is what jade does, the
processor just take the properties it needs. For instance, Jade takes only
the href and type properties and don't know about the format property. Only
the pre-processor does. So, the pre-processor look for the format property
in the PI and do something with it like select the output type and set
appropriate parameters to the processor. which is using the href and type
properties. Thus, if a processor do not validate the PI but just extract the
properties it needs you then have an extensible schema. Each actor in the
chain can use their own properties but from the user point of view, the PI
is consistent and integrated.

The actual schema as the implicit concept of a single output type.
Otherwise, you could select the output format form the PI. Of course, only
HTML is the W3 possible display language but if you open the door to other
rendering engines, you have to provide a way to specify the output format. I
am writing a paper to suggest the new PI schema to ISO and W3. The actual
implementation respect James Clark latest specs, but just add the output
format property for freedom of choice :-)

You obviously have to change the PI for different processors. look at the PI
below:

case a) XSL processor (not necessarily Microsoft but other quality
processors and there are some mostly implemented in Java)
<?xml-stylesheet type="text/xsl" href="../myscript.xsl" ?>
there is, in this PI at least two properties that are either platform
dependent or style processor dependant, not necessarily OS dependant (except
for href and the file protocol). The "type" property is style processor
dependent and need to be changed for each kind of processor (for instance
type="text/xsl" for xsl processor, type="text/dsssl" for dsssl processor and
maybe type="application/x-omnimark" for an other kind of processor and so
on...). The specs also say that the "href" property is a URL. Here is a
valid machine dependant URL: file:d:\Mydir\Di2\MyScript.xsl and an other one
which is location dependant http://www.mydomain.com/Myscript.dsl so, if I
move my script file, I have to change the PI. Thus, the actual PI scheme is
a) location dependant, b) type dependant (obviously) and with an implicit
single output format (by default today: this is HTML for XSL and CSS).

case b) again a XSL processor
<?xml-stylesheet type="text/xsl" href="../myscript.xsl" format="tex"?>
Has the same dependencies as a which means that the type and format
properties are either location dependant or style processor dependant but
not necessarily OS dependent especially if I use HTTP or FTP protocols for
href. This time we added an output format property. This last property is
not OS dependent (look, I used tex and not RTF to be sure nobody sees any
dependencies to a certain manufacturer :-) it is therefore format dependant
and the fact that the workstation(PC, Palmtop or whatever you call that) has
or not the appropriate rendering engine. The last property is not OS
dependant but output format dependant. But this has the advantage to allow
freedom of choice for your rendering and is not more not less OS dependent
as the two other properties.

Chris said:
Irt would be better to have a processor-independent, format-independent,
portable and machine-readable description of what formatting was
intended. That is what FOs are.

Reply--------
OK here is a processor independent, format independent portable PI

                <--------- empty space
It is to not have a PI in your document and have all the processing
instructions outside of it. Is it what you want? There is also an other way:
catalogs. There a catalog standard that allows document systemIDs to be
location independent. It is the equivalent of URN. Each catalog entry
provides an indirection to the real location. Thus a PI would refer to names
instead of URL (especially for href property) and would refer to a name for
the style type (the catalog contains the mapping). We would then have:
<?xml-stylesheet href="MyScriptID" type="MyTypeID" format="MyFormatID" ?>
Thus, I do not need to change the PI contained in the document but only the
catalog entries mapping. There is a major drawback to this scheme, how do I
set the catalog location for an on-line document????
Yet an other way to provide location independency, style processor
independency and output format independency is to use URN but the actual URN
schema is not adapted to properties like format or type only well suited to
href.

Conclusion:
Any actual proposed schema are:(mine which is built on James proposal but
with the addition of freedom of output format choice and James proposal)
- location dependent
- style type dependent (in W3 proposal there is no strict restriction to
only text/css and text/xsl it could be text/dsssl or whatever you want like
application/x-omnimark, and I prefer that to no freedom of choice doesn't
it? )
- format dependent either implicitly like most XSL engine in their present
incarnation or explicitly with our new PI schema proposal.

So Chris, read again 99% of the text and don't get bugged by 0.01% or the
rtf word :-) The proposed schema is not platform dependent. dependencies are
only what I described above.

Didier wrote:
> example:
> <?xml-stylesheet type="text/dsssl" href="../myScript.dsl" format="rtf"?>
> output is RTF and can be displayed in IE browser with the Word viewer or
> word itself.

Chris replied:
OK (the authoritative specification for RTF is where?)

reply---------
Again, replace the word rtf with tex or whatever you want :-) How do call
the capacity to choose? freedom? If someone provides a display engine and
that this engine provides something good, we should be able to use it and
that includes a viewer you would create Chris, not only what was written
somewhere in law tablets :-) So If tomorrow somebody provides a new
rendering engine, I can use it, that's freedom of choice. By the way, RTF
specs are available on the web and nobody restrict anybody to implement a
RTF viewer on an other platform than Microsoft. So, where's the point here?
Religion? I do not say that rtf is better, just that if you choose that, why
not? and again, nobody prevent you to write a rtf viewer on Linux for
instance (in fact that would be a great idea to help Linux be integrated in
the desktop world doesn't it? - I think that Corel WP Linux implementation
will be able to read rtf - Corel is already SGML compliant but I don't know
for the Linux version)

Didier wrote:
> <?xml-stylesheet type="text/dsssl" href="../myScript.dsl" format="sgml"?>
> The output is HTML tags and displayed in the browser. This format gives
you
> a lot of latitude.

Chris replied:
And very little control over the formatting.

Reply---------
Untrue and said obviously without any concrete experience and examples. HTML
is SGML so... are you saying that HTML do not do the job? You may need an
other display engine. Do you?


Didier Wrote:
> <?xml-stylesheet type="text/dsssl" href="../myscript.dsl" format="html"?>
> uses the experimental HTML FOs, still incomplete, but we are working on it
> and we implement new FOs.

Chris replied:
Are you referring to the XSL FOs or to something else entirely. XSL FOs
have no relation to HTML at all.

Reply--------
No, I am not specifically referring to solely XSL FOs but more general FOs.
You are still working hard to find common points to:
- CSS
- XSL
- DSSSL
Flow objects. And we will have to expand our horizons to other FOs also.
There is no real work done on this backend stuff but if we want a clean job,
we'll have to. But this is an industry problem and this is why we all
cooperate in these forum - to find ways to improve that stuff. But there is
tremendous work to do there. So, no we don't restrict to XSL FOs but also to
other FOs and we are working with others in the industry to find a common
ground. But it seems we're a bit too soon on this topic. The focus is still
on style languages.


Didier wrote:
> for XSL and CSS you cannot use the new stylesheet PI, use the previous one
> example:
> <?xml:stylesheet type="text/css" href="../myscript.xsl" ?> in that case,
you
> don't have the format property because only HTML is supported.

Chris replied:
You seem to be equating 'HTML' with 'you see something on screen'. I
don't see how applying a CSS stylesheet to XML to directly produce
rendered output (something that both IE5b2 and NGLayout can do, among
others such as MultiDocZilla and XMetal) involves HTML at any stage.

Reply---------
Good comment. This is not necessarily the case the style engine can directly
do function calls to render. You said Mozilla do that? I work on a Mozilla
implementation and if I include
<?xml-stylesheet type="text/xsl" href="../Myscript.xsl" ?> nothing is
happening :-) so, Mozilla is not really doing script language support in its
actual implementation (work in progress I should say). In fact, we need to
specify an architecture so that style engines could plug into it. This is
what we are working on and are and will cooperate with others in the Mozilla
project for this. But, the actual architecture is still monolithic and is
not ready to include style engines as external modules, as plug-ins yes but
not as an integrated whole. What we need is a style router that just
interpret the "type" property, a mechanism that allows the engine to change
the MIME type and therefore select the appropriate plug-in. For example,
when the style engine encounter the "format" property set to "tex" it can
then tell the rendering engine to load the tex plug-in by specifying the
output type MIME format, or if the format property is not present, just do
direct function calls to the rendering engine. That freedom of choice and
that's an open architecture :-)

Chris said:
Anyway these are minor comments, easily fixed, and i am glad to see the
SGMLKit being updated.

Reply-------
Thanks and thank you for your comments, I could express my views on the
subject. The first implementation is working with IE but we are working also
on an other implementation based on Mozilla but if you have checked the
bugzilla bugs count recently, you probably noticed that we still have a lot
of work to do doesn't it? However, for temerous people, we'll do a release
that allows you to select either Mozilla or MSHTML rendering engine so that,
text processing developpers can check their work in both rendering engine
just by a context menu option. But pieces are rough to integrate and
religion wars are still the builders enemy  (bulders are too much busy
building to do religion war:-))

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


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