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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: xlxp-dev: XSL and editing tools, Chris Lilley | Thread | RE: xlxp-dev: XSL and editing tools, Guy_Murphy |
RE: HTML is a formatting/UI languag, Jonathan Borden | Date | Whither linking, Paul Prescod |
Month |