Re: XSL Trans

[clilley <chris@xxxxxx>]

Paul Prescod wrote:
> 
> clilley wrote:
> > [deletia]
> >
> > I agree that doing good rendering is hard. However, products already
> > exist that have the appropriate algorithms to do the sort of
> > manipulations that are required when formatting text, flowing into
> > containers, embedding images, etc. They can easily take in a declarative
> > (CSS, XSL) description of styling plus a document instance and generate
> > a rendered result.
> >
> > They are called word processors, and it has been observed that it is
> > much easier to add HTTP support to a wordprocessor than it is to add
> > rendering support to a network utility. ... [deletia]
> 
> Idon't think that it is easy to create an editing environment that applies
> an arbitrary transformation to the content 

Not easy but possible (and several members of the XSL WG are from
companies that have traditionally offered editng products so rest
assured that the constraints of editing applications are always being
considered as work progresses.

> and then lets you edit in the
> transformed ("WYSIWYG") view. An extreme example is a stylesheet that
> removes information. 

I have seen products that physically have the editing take place in the
rendered structure and then do a back mapping to the source; however
this is uncommon and actually quite difficult. It is easy to end up with
disjoint selections in the source document, or to be forced to make
radical alterations to the style sheet, or to migrate generated text out
of the stylesheet into the source. This is not a good approach.

Much more common is the approach where certain editing actions (such as
cursor placement) trigger a reverse mapping from rendered structure to
source document, thuis enabling a virtual cursor to be placed in the ,
but that further editing actions (deleting and inserting text, for
example) happen in the source document and are then reflected in an
updated rendered document. This is what all WYSIWG CSS editors do, for
example, and is what many wordprocessors do. The imlementor has to pay
attention to localising updates, to maintain an interactive response,
and certain editing gestures will result in a delay. 

But this seems to be not only simpler to implement but also more
intuitive from a user standpoint. Their mental model may be that they
are editing the rendered document, but they still naturally expect that
if, for example, they edit a subheading and that subheading text is also
present in a table of contents and an index and in some cross
references, that all these occurences are kept in sync.

There can again be problems of disjoint selections, and of small cursor
gestures producing large visual jumps (consider for example editingh a
large list which has been sorted into some other ordering by the
stylesheet). But XML has the underpinnings for support for
internationalisation, so a capable editor will be handling disjoint
selections in any case as soon as it does BIDI.

> How can you edit documents that use this stylesheet
> in a "WYSIWYG" view?  Clearly we are going to need different stylesheets
> (and perhaps a different stylesheet *language*) for word processors.

No, that is not clear at all. I can appreciate how you draw that
conclusion but to me it seems premature and pessimistic. Sure, you will
often want multiple views of the document; you may want to create those
multiple views by using multiple simultaneous stylesheets. You may want
one of those views tobe a more-or-less direct source view, in the way
that for example Adept or Amaya give you source views or tree views. You
may want to disable animations and transition effects and mouseover
events.

But to assert, as you seem to be doing, that XSL is inherently
uneditable and that WYSIWYG editing must necessarily use a different
language, is not supported by the evidence and indeed is readilly
refuted by the presence of a single XSL-enabled XML editor. I expect you
will change your mind once these start being publically available.

There is a mature and extensive published literature on the field of
structured document editing. It is certainly possible, even with
transformations. Incidentally, the source code for Amaya is the product
of around 10-15 years of academic experimentation in this field.

> Disturbingly, we may have some of the same problems on the browser end. If
> you hyperlink to a particular element, and that particular element is
> rendered in six different places, which one does the browser show you?

A menu? 

This example of a single head, multi-tail link is not very different to
a single head, multi-tail link that connects to six different elements,
or six different documents. This increased richness of link expression
became a possibility with the first publication of the Xlink working
draft. XSL doesn't really add much in the way of extra complexity there.

I agree that the single hyperlinging behaviour around which Web has been
gradually coalescing these last few years (click on the blue text and it
loads a new document into the same window) does not support this richer
linking model. 

That is a cause for rejoicing, not concern.


--
Chris


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