Re: xlxp-dev: XSL and editing tools

Subject: Re: xlxp-dev: XSL and editing tools
From: Chris Lilley <chris@xxxxxx>
Date: Sun, 25 Apr 1999 01:38:00 +0200

Paul Prescod wrote:
> 
> Kay Michael wrote:
> >
> > I think the real problem is that XLink as currently conceived has a lot of
> > presentation semantics. In XML I usually represent relationships using
> > database-style foreign keys rather than XLink-style URLs, and I regard it as
> > a function of the rendering process to translate these foreign keys into
> > navigable hyperlinks where appropriate.
> 
> I agree with everything you say.  I don't think that it addresses the
> point of the post, however. Links are not the problem. Editing a
> transformed view of a document is the problem. It isn't at all clear how
> edits in the view are translated back into edits in the source document.

Aha.

Think of editing a text file in an editor, and asking the question "its
difficult to see how the changes to the pixels on the screen are
translated back into changes in my text file".

Most likely, the editor is keeping track of where your cursor is in the
file and making changes to the text file, and then redisplaying the
modified text file.

It would be very unusual if it was reading the screen, OCRing it, and
trying to work out what to do to the text file ;-)

Similarly, an XML editor that wants to display a WYSIOP[1] view of the
document is most likely editiong the source XML file and re-applying the
stylesheet each time the XML changes.

> Suppose I add an element to a sorted list -- in the sorted view. Where in
> the unsorted source document does that element appear? Suppose I add an
> element at the point where a some element has been suppressed. Does the
> new element go before or after the suppressed element? etc.

These are all good questions, and the usual answer to them is "you don't
do that". Instead, good editors provide feedback as to where the cursor
is in the source document (such as giving the current context, similar
to an XML Fragments context).

To answer your specific questions - the new element would most likely go
after the element that you added it after, in the source XML. Then, the
document would be redisplayed, which might move the new element so that
it was still a sorted list. 

I have seen a few products which tried to directly edit a transformed
presentational document, and they generally had worse and worse problems
until they stopped trying to drive things backwards.

[1] What You See Is One Possibility
--
Chris



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


Current Thread