RE: Announcement

Subject: RE: Announcement
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Thu, 28 Jan 1999 19:02:20 -0500
HI Chris,

OK The specs says nothing about HTML.

The actual state of the art is that only Microsoft browser beta version
includes a XSL Processor.
Most of the XSL style sheets we see in this forum are creating HTML
documents or are producing HTML tags no? Just look in the archives.

These are facts, not fiction.

Yes it is possible that a browser includes a xsl processor that use
formating objects to render directly, so do DSSSl which is I should recall
is an ISO standard. In fact, our implementation is doing that with a WMF
backend (work in progress) we are also working on an implementation plugged
directly to the NG mozilla engine.

However, there exist one _standard_ dsssl and an other one in progress XSL
and one already a standard CSS. If you choose to link your document with a
stylesheet, you'll have to set it in the PI right?

If again, you choose to get your document rendered with a special format
like for instance Tex (not text) or rtf (because the document producer have
good reason to do so) and if your browser allows you freedom of choice, you
then have to be able to specify the output format in the PI. However, I
should say, that it is not a good way to ensure location independency but if
this is not important then PI is OK.

The rule should be that all agent in a process chain should only pick PI
properties they need so that the whole construct is consistent. Current
proposal (not spec... proposal) specify even a media property wich could be
set to tty???? so maybe the media property could be used instead of the
format property and just get its set of values expanded. Just read
attentively the stylesheet PI Proposal.

what you say about vendor dependency and stylesheet processor will be
imposed by browser market share. Sorry, it is market reality and even if I
would I cannot change that. The browser that includes a XSL engine and has
the biggest market share will impose its law. But yes, if style processor
(not in the hardware sense but the software sense) is following the specs
(hard to do, specs are often defficient) or repect most of it, I can, by
using the subset used by everyone run my stuff on an other style processor.
At least in theory....

About rendering in other format, you have downloaded or installed your
borwser someday no? What we need now is not a single religion but a common
mechanism (like plug-ins or whatever) to get the required rendering engine
and ideally get the freedom of choice to choose our provider. What you are
implicitely suggesting is that there is only one single renderer is it that?
If not, what is your suggestion then?


you said:
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).

What's the difference with
<?xml-stylesheet type="text/dsssl" href="foo.dsl" format="rtf"?>
I could be on Linux use an other dsssl engine than Jade and a viewer other
than word, I could even have the choice of 10 different viewers. so where
the point. In theory no differences between your sample and mine except the
market realities. You won't have 10 aural choices and that will be imposed
by the dominant browser, isn't it?

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

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

Reply:
me too but reality is that the file URL or even the HTTP URL is location
dependant as stated in the RFC (because of its DNS context)


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

Reply:
exactly same for type="text/css" and text/dsssl". Same for CGM so I I get
format="CGM" I can choose my CGM display provider at least in theory :-)

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

Reply:
No and now If you dont have a browser supporting XSL, only CSS and you
download a XML document having a PI indicating a XSL engine to format the
document what do you do then ? same problem isn't it? Or if the target
browser do not support some of the style instruction you use in your style
sheet, what do you do?


Didier said:
> 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:
I assert that it removes feeedom of choice by requiring certain details
of the internal implementation to be a certain way.

Reply:
So, let evebody have a single browser, a single type of machine a single....
Isnt't that a bit utopic no? Freedom of choice is that, I choose not from
specs on paper but real product and real implementation and the recent
history showed us that specs are hardly repected, Look at CSS. Can you now,
send a HTML page having CSS to everybody on the web and be sure it will be
rendered OK and even more rendered the same way? Lets's get a bit more
realistic here.

> 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

Chris said:
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).

Reply:
OK, what will decide to use MacInTalk or JSML, the browser or something
else, That something will then impose your choices. Isn't it? So no more
freedom here. However, I should say that I agree with the media property (I
am probably more open to good ideas it seems or maybe less religious)

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

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

Reply:
I agree that linkage should be separate because URL are location dependant
(except if the URL behaves as a URN) We should have either a mechanism like
URNs. Things like Hytime already resolve that issue and XLink (a Hytime
subset) may resolve that. What that will be pratically is an other story. We
already have a lot of expenrience with Hytime and saw the problems invloved
with that, so imagine on the web now. And even worse, we have a legacy now,
the web like it is now, we'll experiment problems Microsoft gets with
installed base and that IBM got before. The story repeats itself.

Didier said:
> 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.

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

Reply:
Agree 100%, this is real idenpendence at it also means adaptablitily to real
environement PIs are a big patch. For the legacy again. We have to be
patient and start from the here to there.

Didier Said:
> 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????

Chris reply:
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).

Reply:
Good idea, I have to think of the implications, but at first impression
sounds like a good idea.


Didier said:
> 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.

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

Reply:
URN provide location independency by providing a name. A resolver has to
tranform that name into a location. thus, you can have a document identified
by a URN and change its location without affecting the original document.
Orherwise, you have to modify all documents having the URL. URNs provide
indirection (ref RFC 2141). I worked a while with the URN workgroup and we
got some arguments about relative URNs (still not resolved) we even
implemented a grove wcich is URN based. You can implement your URN resolver
like you want and you are not restricted to the NPTR DNS record.


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

Reply------
Yes I agree.

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

Reply --------------
I don't follow you there. Let'S say that you have a document viewer acting
only as a frame. In it I can run any viewer like tex, CGM, whatever... My
scheme just say, load the CGM viewer because, in the actual state of the
art, CGM will render the document in a better way than let's say RTF. Your
document viewer should be able to pick the CGM renderer to display the
document. It is up to you to choose the best one from the vendor of your
choice. No?

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

Reply----------
Not necessarily if nothing do the job on the market. Remember that
"Everything has been invented" the patent director beginning of this
century. You don't want to say the same thing don't you? So, the media
property would be insuficient if you want to render with your new stuff
which would be falling in the "screen" category. You know a lot of stuff
could be categorized to fit in the "screen" category doesn't it? But I would
say that an intelligent browser and an intelligent web would point you to
where you can get this viewer. And the producer can also say that if the
"xxx" format is not there, then use this other format and alternate
stylesheet. This is what we should talk about:

How do set a PI that would allow alternate choices on the target machine.
This until we have a more intelligent mechansim


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

 Reply ----------
Not necessarily, two renderers could be totally different I can choose among
several CGM renderer having all different internal mechanisms and
efficiency. I do not say use that one with that function call in it, just
use a renderer for the CGM category. IN the future, when the industry will
set that a certain kind of format is the utlimate rendering engine, you
won't have to do that. But we are far from that no?


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

Reply-----------
It is not my proposal which is doing that. It is the Style sheet PI. And
your comment about any particular vendor is not relevent to the addition of
the format property. That facet is more driven by market shares and now by
government regulations (if Microsoft is declared a monopoly, we'll have an
other utility company like phone etc...But anyway that's already the case).
And Rtf is not only used by Microsoft, it is used also by Corel. If corel do
not have a big market share and rtf having not enough different vendors, it
is not my proposal or your will that wil change something there only market
dynamics.


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

Reply-------------
This is not what I am saying. The browser could let the user choose it
rendering engine and the provider could say if his document and style sheet
can be rendered either with the provider specs or with an alternative.
Anyway, again, the way XSL will be used will impose de facto that only HTML
rendering will be permitted, so, no more freedom here especially if the only
browser supporting xsl for a while is microsoft browser doesn't it?

--------------
> 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)
Reply-----------
I agree, in the actual state of the art, we need other rendering engines :-)


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

Reply----------
I am sorry, please accept my appologies.

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

Reply----------
I agree, but be sure that actual implementation will be built on top of HTML
rendering. It will take a while before we get further.

-----------------------
> 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.
 Reply-----------
No I mean formatting object. But we need to agree on a whole architecture
about what each formatting object is and do (translated into action), FO
that could work with dsssl, css, xsl etc... all with the same FO
architecture.

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

Reply-----------
this is true, Mozilla does that. The actual Microsoft XSL engine just
produce HTML wich is then converted into rendering object internally. This
is why XSL rendering is so slow on IE5.x Imagine, I have the same
performance with the dsssl and even better one on long documents and I have
to start a separate process !!!! (the stuff is not optimized yet)

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

Reply------------------
Yes it does something but I agree it does not implement the whole spec. It
seems also that people prefer what already implemented more than formatting
object stuff.

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

Reply -----------
Or the proposal done for the NETAPI, this can allow plug and play protocol
handlers.

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

Reply--------------
No, only that market realities makes that not all borwser are equal, thus
some will need a plug-in added, some others more advanced could gracefully
dowgrade to its own internal engine or be enough advanced to download what's
required or be sophisticated enough to render all these format as well as
they should do. It is all implementation dependent, you just tell to the
browser the quality of service you need. If you say format="CGM" that is the
level quality you need. The browser may not have the same level of
sophitication to offer you the same display quality as a CGM viewer if the
internal rendering engine is not enough sophisticated. We all know how hard
it is to be a good renderer for all kind of format from CAD drawing to 3D
models etc...In fact, no borwser do that actually without the help of
outside plug-ins with re-enforce my point about the format property. It just
tell the level of rendering quality you need for your document.

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

Reply--------
OK Chris, That's your point. But up to now I have not found your counter
arguments strong enough againt the format property except that browsers
should be able to do any kind of rendering (i agree on that) but the state
of the art is far from that no? We still have a lot to do until then, so we
need intermediary steps. And when a browser will be so domimant we'll have
an other court session about monoply stuff :-)

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

Reply----------
That is not dependent on what we'll implement but more on how stylesheet
developer will do. the story won't change, browser won't be equal and we'll
have to find the common subset,choose the bigest market share or do server
transform into HTML instead of XML documents rendered on client's browser.
However, the DSSSL engine will be the same and at least this part will be
consistent. But we cannot control what's produce with the style sheet.

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

Reply---------
And also has increased the bug count....

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

Reply----------
This is already the case either with Netscape version or Microsoft version.
Don't imagine that we invented the format schema for taking the world or
injecting proprietary stuff, Netscape and Microsoft did that very well
before us. It is driven by real customers needs and actual state of the art
of browsing tools. What you are saying is that only these two players are
allowed to play in this game. the format property is not worse than having a
URL for the href. And some other properties are not even practical. Just
imagine choosing media="aural" with a CSS  stylesheet having
background-color???? So what this means is that I have a set of properties
that could or not be included dependant on the context. Format may be useful
for a while like href is. But both href and format will have to be obsolete
when the state of the art will be more advanced.

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


--
Chris


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


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


Current Thread