From: "Paul Prescod" <paul@[...].net> 

>  Dare Obasanjo wrote:
>  > 
>  > Exactly what is inefficient about putting open tags in a stack as you see them
>  > and popping them off as the tag is closed with soem flag that halts this
>  > process when withing CDATA sections? Is there some sophisticated nuance I've
>  > missed?
>  
>  When are you doing this pushing and popping? The user opens a hundred
>  megabyte document and scrolls to the bottom. They insert the cursor and
>  try to close a tag. There is no way to know the context without parsing
>  from the top in real-time. Plus, you need to deal with documents that
>  are not well-formed so you can't use a regular XML parser.
>  
>  I don't mean to say it is rocket science, just that it certainly isn't
>  as easy as it seems at first.
 
I think this shows the fundamental divide in XML editing: people who
can edit in trees (i.e. WF XML) and people who need to edit text
(i.e. non-WF XML, HTML, or minimized SGMLs).   

Why do so many people still edit in programmer's text editors rather
than the specialist XML tools? Apart from issues of deployability,
I think it is mainly because, for many people, the time when they
have a well-formed instance is often the time that document is _finished_ being
edited.  Obviously editors which store the document internally as a tree
have a lot of overhead for large documents which text editors do not have.

This is why many XML editors are morphing into XSLT IDEs: having the
data in a nice tree it is easier to add features for to different views and
transformations. 

XML editors which "prevent you from making mistakes" or "hide the tags"
are usually based on tree data-structures. But users who need to
mark existing data up, or to clean auto-processed documents up need
the opposite: assistence in detecting and repairing mistakes in any the order
that the user (or the team's division of labour) requires, and maximum
access and clarifiation of the markup.  It is possible to make editors
which stand in between Emacs and Author/Editor: but to do so 
means not basing the editor either on maintaining a bulky tree or
zipping back and forwards constantly with regular expressions:
it is not something that can readily be retrofitted onto Emacs or 
the Author/Editor-style of editors.

An editor based on incrementally validating a document which may
have "islands of interest" (i.e. only the tables are being worked on,
the rest of the document is not-well-formed and not valid) to the extent 
of the markup available in that island has to treat schemas and DTDs 
very differently from how they are typically utilized currently: you 
cannot use DOM-based tools in the same ways as currently. 

To support this kind of editors,  it would be useful have to adapt
minimization indicators of SGML's DTDs to XML Schemas (and
RELAX NG), using some kind of <appinfo>  annotation. That feature
in SGML is very useful for editing. It tells you, for example,
that when you go
   <ul> <li>Hello <b>world
    <p> Hello
 that filling in the end tag for <b>  and <li> is something that can be
safely done automatically, but filling in an end-tag for the <ul> 
is something that user probably needs to be asked to supply.

Cheers
Rick Jelliffe

Topologi Collaborative Markup Editor
http://www.topologi.com/


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>