Metadata for XML editors and copy/paste histories, part 1

How many times have you copied something from point A to point B within a document, only to realize you messed up something in point A, and have to fix both A and B?

Personally, I’ve done that lots of times. It’s annoying. If I did that, I’d much rather fix A and let my editor detect the fix, and propagate it to B. It’s the sort of optional feature that would make an editor into a killer app, I think.

Having not yet done any formal research into how others have approached this, I decided to start writing up a spec on how I would do it for a XML editor such as Verbosio. I know I am extremely stubborn and want to try to figure this out – so I’m posting now (before I waste too much time) to see if anyone else has looked into this, and hopefully, written up specs for this before.

In short, I’m starting to design two specs. One for storing metadata about a document that XML editors can commonly use, and one for recording copy/paste histories in that metadata, in order to propagate fixes from early content to later similar content.

Please, someone stop me with some great ideas others have already written about! Otherwise, I will post a blog article later describing the start to a new approach.

UPDATE: Wow, this is hard. I had an idea I was starting to formulate, but then I started trying to simulate it…

3 thoughts on “Metadata for XML editors and copy/paste histories, part 1”

  1. You are projecting textranges in the MARKUP to other locations within the markup? We are not talking about the rendered VIEW of the document?
    (From Alex: Huh??? What’re you talking about?)
    For both purposes, it appears elegant to use XInclude syntax for metadata. But in the first scenario – which I suspect you are after – you would have to finalize the partly implemented XPointer evaluator for it to work smoothly, since this is needed to identify fragments in simple text. If you settle for copying on an element basis (as opposed to textranges), the second scenario is relatively easy, since you could simulate a simple-syntax XInclude parser with XPath. For a point-and-click interface you can even use you fancy new XPathGenerator.
    In the syntaxhighlight posts you considered constructing the markup-editor as a view to an underlying document; like the view-source page in Firefox. In that case, the second scenario apply. You can introduce elements at will and not worry about XPointer. But from a performance perspective, a syntax-colored editor composed as a rendered view is probably not a good idea. A real plugin is the way to go.
    (I hate to disappoint you, but this is something completely different than the syntax highlighting posts.)

  2. Sorry – I hadn’t injected my morning coffee. Probably digging a hole for myself, but since nobody has volunteered with other comments: You have the source code of a webpage (the markup). And then you have the rendered webpage in the browser (the view).
    Duplicating document content in “the view” can be done smoothly with XInclude statements. If you use id attributes in your XPointer expressions, the setup can be pretty resistant to document modifications.
    Duplicating content in the source code is different. Since there is no entities to duplicate, you’d have to work with, whatever, regular expressions or character indexes. “Copy 23 characters, starting from position 203, to position 451”. Not very resistant to document modifications.
    (From Alex: That’s where XPath and my XPathGenerator enter play.)
    Now – in the syntax highlight posts you entertained the idea that the source code editor could be constructed like the view-source page in Firefox. It is source code; but it is also the “view” of another source code – the hardcore tag soup underneath – meaning you can go back to duplicating content with XInclude.
    OK. Theoretically you *could* have used XInclude statements for the plaintext source code to begin with, although they would not appear in the sourcecode, but in some separate metadata file. XPointers do have control over character indexes in text strings, but this text-range-dissection part of the XPointer specification is, to my knowledge, not implemented in Gecko. So you would have to go by the stuff that can be emulated with XPath expressions; and these don’t work for plaintext.
    Point was to raise attention to XInclude, since here was a certified specification dealing with content duplication. You may erase my posts to invite other feedback. I wasn’t even sure about the question – are we duplicating content in the source code or the rendered view? – in the first place.

Comments are closed.