Re: xlxp-dev: XSL and editing tools

Subject: Re: xlxp-dev: XSL and editing tools
From: Paul Prescod <paul@xxxxxxxxxxx>
Date: Sun, 25 Apr 1999 11:12:15 -0500
Chris Lilley wrote:
> 
> > 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.

Right. This is exactly why I cannot use XML editors in my work when I
collaborate with someone who cares about the layout of the text file.
Unless the editor's idea of the "proper" layout of a text file is
congruent with my co-author's, it will make the wrong back-mapping. Most
people can get away with using an XML editor (thank goodness) because they
have decided that they DO NOT CARE about that back-mapping, beyond simple
stuff like "insert line breaks yes/no", "line break at: 80 chars", etc. 

This is an important point: they have made the decision that this
particular backmapping is not important! If they wanted to put a tab
between the element type name and the first attribute name then they can't
do that, but they've decided that they don't want to. In most cases this
is fine.

Now move it up a level and consider the case where we are talking about an
XSL-generated view over text. 

First, you have the problem that the result of the "back-mapping" is
constrained by the underlying DTD. In other words general rules of thumb
like "break at 80 chars in PCDATA" do not work. There is no general rule
that can say "unsort the elements so that they conform to the DTD". The
right "unsort algorithm" varies from DTD to DTD!

Second, there is the more philosophical problem that authors should not
have the right to *not care* about the back-mapping. Not caring about the
mapping to text file is something that even most purists can accept. But
not caring about whether an element is the fifth or tenth in its parent
element is not right: order matters in XML. The fact that you found some
XSL stylesheet on the Web that happens to sort the elements in one way is
not evidence that the original order is never significant. I might sort
the lines in Shakespeare by speaker in one view, but if you are going to
add a line to one of Shakespeare's play you'd better think carefully about
where it goes in the chronology!

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

So I'm editing in one view but the editor is telling me about my context
in an arbitrarily different view? And how does it do that? What is the
right user interface to tell me that there is an invisible, suppressed
element at a particular place and I must make a choice of whether my
element goes before or after it?

> To answer your specific questions - the new element would most likely go
> after the element that you added it after, in the source XML. 

I don't understand this. Here is the original document:

<FOO>
  <FOO1>This is the title</FOO1>
  <FOO2>This is alt text.</FOO2>
</FOO>

This is the rendition:

<BLOCK>
   <P>This is the title</P>^
</BLOCK>

My cursor is at the carot. I insert a "BAR". Does it go before or after
the "ALT"? What if that invalidates the document? What if it doesn't
invalidate the document but one ordering means one thing and the other
ordering means something completely different?

Here's another case for you to puzzle out:

BARs occur at multiple levels with varied parent elements but cannot occur
at the top level.

<FOO>
   <BAZ1><FOO2><FOO3>....<BAR>...</BAR>...</FOO3></FOO2</BAZ1>
   <BAZ2><FOO2><FOO4>....<BAR>...</BAR>...</FOO4></FOO2</BAZ2>
   <BAZ3><FOO2>....<BAR>...</BAR>...</FOO2></BAZ3>
   <BAZ4><FOO5>....<BAR>...</BAR>...</FOO5></BAZ4>
   <BAZ5>....<BAR>...</BAR>...</BAZ5>
</FOO>

Now here's the view of FOO produced by the stylesheet:

<BLOCK>
    <P CLASS="BAR">...</P>
    <P CLASS="BAR">...</P>
    <P CLASS="BAR">...</P>
    <P CLASS="BAR">...</P>^
    <P CLASS="BAR">...</P>
</BLOCK>

Now I insert a BAR at the cursor. Does it go within the same FOOx that the
preceding BAR did? Or does it generate another containing FOOx? And if so,
which FOOx? Or does it go all the way up ot the top-level and generate a
new BAZx? And if so, which BAZ? And does it make a different choice based
on the constraints expressed in the DTD?

Let's try another. I find a stylesheet on the Web that transforms this:

<FOO><BAR>Text1</BAR><BAZ>...</BAZ></FOO>
<FOO><BAR>Text2</BAR><BAZ>...</BAZ></FOO>
<FOO><BAR>Text3</BAR><BAZ>...</BAZ></FOO>
<FOO><BAR>Text4</BAR><BAZ>...</BAZ></FOO>

into this:

<P>Text1</P>
<P>Text2</P>
<P>Text3</P>
<P>Text4</P>

Now I highlight the line containing Text3 and delete it. Does that:

a) delete the <BAR>Text1</BAR>? What if that invalidates the DTD? What if
it doesn't?

b) delete the text contained in <BAR>Text1</BAR>? (It isn't yet possible
for a deletion of text to invalidate a DTD, but in the future it will be
possible for it to invalidate a schema)

c) delete the entire containing FOO?

d) beep that the thing can't be deleted. If the latter, then what
algorithm does the tool use to decide when things can't be deleted?

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Company spokeswoman Lana Simon stressed that Interactive 
Yoda is not a Furby. Well, not exactly. 

"This is an interactive toy that utilizes Furby technology," 
Simon said. "It will react to its surroundings and will talk." 
  - http://www.wired.com/news/news/culture/story/19222.html


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


Current Thread