Lists Home |
Date Index |
On Tue, 2002-03-19 at 11:18, David G. Durand wrote:
> At 11:01 AM -0500 3/19/02, Simon St.Laurent wrote:
> >Maybe Ted Nelson was right about out-of-line markup having advantages.
> Of course he was. There are also disadvantages, to do with the
> increased complexity of editing models for such representations. You
> have to either update the offsets as the underlying text changes, or
> create a text model that does that for you. Maintaining link
> integrity was the reason for much of the work that Xanadu did
> tracking text across versions. It's possible, but the tradeoff is the
> need to create an efficient way to update the offsets.
Right. Reducing the need for metadata and metadata relationship
maintenance is a lot of why I prefer information explicitly embedded.
> Plus, well-formedness becomes trickier because the representation
> accommodates non-hierarchical structures as well as hierarchical ones
> -- good if you need or want that flexibility, bad if you don't.
True. Part of the reason I've developed MOE is to make it possible to
work with "ill-formed" structures, though well-formed is easier as
usual. That may make it easier, or at least possible, for me to deal
with intermediate steps between jumbled hierarchies and clean ones.
> >Does anyone know of an XML implementation which provides read/write
> >access to the contents of elements in the document as text, and makes
> >changes to that text - including the insertion of new elements - to the
> >elements underlying it?
> I'm not clear about the solution that you're looking for, though. Are
> you asking for an interface that can do an operation like:
> Element.insertTexttext("this is a <emph>subelement</emph> embedded in
> text", location);
> and the result will create a modified element tree with a new element node?
> I'd be surprised if you find one, because that's a rather "non-node"
> way of looking at things.
That's pretty much the answer I was looking for. I'm tired of dealing
with a purely node/Infoset view of XML documents, so I'm looking for
alternatives. If this is open frontier, that's fine too.
I'd just rather not reinvent wheels without knowing the wheels are
there, and it might have been nice to build a prototype if they in fact
> > Anything crossing element
> >boundaries will be difficult, but hopefully not insurmountable.
> This last point puzzles me, because I'm not sure how such an
> interface could "cross" boundaries.
If I wanted to replace text that was partially in one element and
partially in a sibling, there'd be a lot of juggling to do. It may not
be worth bothering, but it's worth considering.
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!