[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: Announcement

---

---

Didier PH Martin wrote:
> 
> Hi Chris,

> 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? :-) 

We seem to be talking entirely at cross purposes here.

The PI is in the xml document. It points to a stylesheet, either CSS or
XSL. CSS is written in CSS syntax and XSL is written in XML. And lets
assume that the intent is to proiduce a rendered form of the document,
rather than to transform it into another stored document. HTML comes in
where, exactly? Not only is it not restricted to HTML, HTML is not
involved at any stage at all.


> So, the actual scheme for sytlesheet PI is
> that the output is not selected and therefore implicitly stated to html

Its this bit about HTML I don't understand.

> if I
> look at the actual implementations. Do you know one XSL processor who does
> output in rtf or tex?

There are very few XSL processors, and only one that I am aware of which
tries to implement the whole style sheet spec rather than using parts of
a style sheet spec as a non-style-sheet, which is what all the others
do.


> 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 unstructured bag of processor directives is ok as long as it is
clear which directives apply to each processor. Saying 'format=tex' is
no help to some other, non-Jade processor which happens to have, say,
two text back ends which are different in some way.

> 
> 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 

Again you make this assertion that HTML is a display language - it isn't
- and also that HTML is 

a) a W3C display language
b) the only W3C display language

I can confidently state that both assertions are false.

> but if you open the door to other
> rendering engines, you have to provide a way to specify the output format.

No, that is not a logical consequence. *One* way is to do that. Another
way is to describe the desired formatting in terms that are independent
of the rendering engine. Document instance plus tyle sheet ==> tree of
FO. Those FO can be formatted by an engine that uses TeX, PDF, Win32
GDI, OpenGL, XLib, or loads of other things that dont even exist yet and
I , the stylesheet author and document author do not have to know or
care.


> 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 :-)

Freedom of choice is a great thing. Your changes to the PI limit that
choice. "This document only viewable if the XSL implementation uses TeX
as an intermediate target" removes choice.

> You obviously have to change the PI for different processors.

No, you obviously do not.

> 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 

No, any implementation of the XSL styleshet language processor could use
that PI and that stylesheet and render the document. On any platform.

>(for instance
> type="text/xsl" for xsl processor, type="text/dsssl" for dsssl processor

That is not a change of processor - it is a change of style sheet
language.


> which is location dependant http://www.mydomain.com/Myscript.dsl so, if I
> move my script file, I have to change the PI. 

or issue a redirect. But, yes. (And my personal belief is that ideally
all machines would have an HTTP server running - which might well block
all access except from the local machine, but still running - and file
urls would disappear, So redirects, content negotiation, all that good
stuff would work).

But this is tangential to the topic at hand.

> 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).

but not dependent on the particular processor for each style sheet
language. I acn use one from vendor X today and a better one from vendor
Y next year, without changing a thing.


> case b) again a XSL processor
> <?xml-stylesheet type="text/xsl" href="../myscript.xsl" format="tex"?>
> [...] This time we added an output format property. This last property is
> not OS dependent 

OK, my point about rtf was orthogonal

>  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. 

Yes, exactly. So if someone downloads this document and style sheet and
has an XSL implementation which can process it but happens not to use
TeX internally - maybe it uses something else, writes directly to some
internal wordprocessor format because the processor happens to be a
wordprocessor with a "Load from Web" option on the file menu .. whatever
... they don't have the rendering engine you were thinging of but they
do have the ability to process the XSL stylesheet. You are saying the
document should not be displayed?

> The last property is not OS
> dependant but output format dependant. 

Agreed. That is what makes it a bad idea.

> 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.

I assert that it removes feeedom of choice by requiring certain details
of the internal implementation to be a certain way.


> Chris said:
> It 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

Here is another one 

<?xml-stylesheet type="text/xsl" href="foo.xsl" media="aural">

It is processor independent (any XSL processor which implements the XSL
stylesheet language can be used) and is format independent (I don't care
if you use MacinTalk, Via Voice, JSML, Sabre, talk directly to a custom
DSP or anything else).

> It is to not have a PI in your document and have all the processing
> instructions outside of it. Is it what you want? 

Well actually yes but that is also orthogonal. But let me explain why I
want it. Suppose I have a bunch of XML files that I cannot change - for
example, they are on someone elses Web server. Or, for example, they are
on the XML98 CD, which is read only. Lets suppose they contain a hard
coded PI (which they in fact do) and lets suppose I don't like it (which
I in fact dont, it iuses vendor specific extensions masquerading as a
standard XSL style sheet).

And lets suppose that I have an alternative style sheet which I consider
superior (again, I do) and want all those document to use it instead. I
cannot.

This is something that out-of-line XLink can help solve.

The problem is that originally, the link was to the document (an HTML
document or a osrtScript document, in the original Web implementation).
No inline images, no style sheets, no audio.

Over time, images, styleshets, audio, video etc were added and all were
linked from the document (because we had to have a single URL still). In
retrospect this was a bad idea. The document is serving two purposes:

a) a document - textual content
b) a manifest, linkbase or catalog of resources required for a compound
document

These should, in an ideal world, be separate.

> 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. 

Yes - aha at least we agree. Well actually I agreed with most of your
initial post, just disagreed strongly withsome of the details. And in
fact you can use URIs in that catalog as well. Or a simple XML schema
would suffice.

So the one URL which you bookmark or follow from a page would point to
the manifest - or catalog - which would contain purely a list of
resources, the type of each, etc. No actual content, although one (or
more) of the links would point to an XML file.

It would be feasible to have proxy caches read these and prefetch all
the items in parallel, for example, so by the time the browser started
laying out the content all the resources were lined up ready in a nearby
proxy cache. And it would mean that I could use a different stylesheet
merely by editing the manifest and doing a redirect from my local web
server.


> Thus, I do not need to change the PI contained in the document 

right

> 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????

You point to the catalog, not to the document. The manifest idea that I
have would be applicable to a group of related documents, wheras SGML
Open calalogs (which is what I think you are describing) are independent
of documents and in my experience point more to dtds, entity files, etc.
But something similar could be used (I would rather it ws in XML than in
some different format).


> 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.

Not sure what you mean by that paragraph. Could you explain?

> 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

sometimes

> - style type dependent 

yes

> (in W3 proposal there is no strict restriction to
> only text/css and text/xsl it could be text/dsssl or whatever you want 

correct

> like
> application/x-omnimark, and I prefer that to no freedom of choice doesn't
> it? )

Well if you are pointing to a style sheet then you probably have an idea
what style sheet language it is written in. But you shouldn't be
requiring implementations of that stykle sheet language to be written a
particular way or use a particular internal representation - that
removes rather than increases freeedom of choice.

> - 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 :-) 

I agreed with 99% or so. I disagreed, strongly, with 1%.

The proposed schema is not platform dependent. 

yes, agreed.


> Again, replace the word rtf with tex or whatever you want :-) How do call
> the capacity to choose? freedom? 

no, restriction

> If someone provides a display engine and
> that this engine provides something good, we should be able to use it 

yes, absolutely, We should be able to use it if it is good. Your scheme
prevents that.

> and
> that includes a viewer you would create Chris, not only what was written
> somewhere in law tablets :-) 

Yes, I could write my own proprietary undocumented processor. And I
could start requiring the use of its internal fornmat in all XML
documents that I wrote. I could, but it would be an exercise of little
value.


> So If tomorrow somebody provides a new
> rendering engine, I can use it, that's freedom of choice. 

No, you blocked being able to use it by being overly specific about how
it was constructed internally.

> 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?

The point is that I do not want to see XML document onthe web which
point to stylesheets and say you can only view these documents if your
stylesheet implementation is from a particular vendor or uses a
particular internal format. Your proposal seems to make that more
likely, which is why I am so against it. 


> Religion? I do not say that rtf is better, just that if you choose that, why
> not? [...] nobody prevent you to write a rtf viewer on Linux for
> instance 

Note that the W3C proposal would allow you to use theis Linux RTF
vierwer - or anything else - wheras your proposal would *require* the
stylesheet to be interpreted by generating RTF and no other way -
removing freedom of choice.


> 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 

No, I assert quite confidently that HTML gives you remarkably little
control over the formatting (that is actually intentional)

> and said obviously without any concrete experience 

Now you are descending into mere name calling, so I refuse to follow. I
know what my level of experience is, you do not.

> HTML
> is SGML so... 

which it is, but the converse is not true.

> are you saying that HTML do not do the job? 

Of course!!!! That is why W3C started work on style sheets in 1994, why
I got involved in that work in 1995 - because HTML is incredibly poor at
being a display formatting language (hardly surprising given the design
principles) so, to save HTML from being an interoperabilioty disaster
and also to improve the extremely poor level of formatting control on
the Web, that is why W3C started work on a non-HTML description of
rendering - style sheets.

> You may need an
> other display engine. Do you?

Yes, you certainly do. One in which HTML has no part to play whatsoever.



> 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.
> [...] 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.

Yes. My focus (and inded the XSL WG focus) is style languages; and
Formatting Objects are clearly to do with style languages. If you are
using the term to mean something else, then I can't know what you are
describing. Its as if we were talking about cars, and then you said you
were using the word car to mean cheese, or lightbulbs. I can't follow it
any further until you say what you mean with your redefinition.

> 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. 

Right. Or it can generate a tree of FOs and interpret them, internally.

> You said Mozilla do that?

Yes. Go look at the source code. You will see rendering objects in
there, which are similar to XSL FOs. When NGLayout takes an XML document
and a CSS stylesheet and displays it, as I said, at no point is HTML
generated. This is not hidden information, although it is not widely
known either. My understanding is that IE5 also does not produce HTML
when rendering XML documents with CSS (but I have not seen the code).

> I work on a Mozilla
> implementation and if I include
> <?xml-stylesheet type="text/xsl" href="../Myscript.xsl" ?> nothing is
> happening :-) 

Right, it doesn't do XSL at this point. Similarly, in IE, nothing is
happening because it doesn't do XSL at this point (it does one part of
the spec but not the other part).

> 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. 

Like the modular font renderer, for example, the same way that works?

> 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.

Ah now you are saying something different to what you said before; if
you have format=tex and tex is not present it can go interpret the
stylesheet with whatever other renderer it has. And if the format
property said format=foo then it should use the foo renderer, otherwise
use whatever it wants.

So lets suppose that I have two browsers A and B; A has a good TeX
engine but its foo support sucks. B has a really basic TeX engin but an
amazing foo engine. What do I put into the format property to get the
best output? It seems I need to pick A or B and have "best viewed in A"
in my document. Or, I could rely on the browser to use the best engine
it has - so th eformat property is redundant.

>  That freedom of choice and
> that's an open architecture :-)

No, in that case it is not freedom of choice but in that case it is not
the restriction of choice that I said earluier; it is just redundancy,
and tuning to particular implementations at the expense of others.
> 
> 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 

And the same XML document will work with both, or will I need to go
editing the document because it is targeted at a different
implementation of the same spec? And when a million readers download the
document are they supposed to edit it too, to give precise details of
the internals of their style sheet rendering process?

> 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 

Both of the rendering engines that you mention are far from perfect. The
recently released CSS1 test suite will help drive these implementations
towards better conformance.

> so that,
> text processing developpers can check their work in both rendering engine
> just by a context menu option. 

That sounds useful. 

> But pieces are rough to integrate and
> religion wars are still the builders enemy  (bulders are too much busy
> building to do religion war:-))

I'm not trying to start a religious war. I'm trying to ensure
interoperability. Hard coding details of a particular implementation
into an XML document does not strike me as the path to happiness. 

--
Chris


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

---