[
Lists Home |
Date Index |
Thread Index
]
I'm not saying that I want the editor to guarantee that the document is
well-formed. Auto-completion of closing tags with the {'</' = complete
closing tag automatically} is independent of the WFdness of the document.
If I don't want to close a tag, then I don't type '</', that's all. If I
want to close a specific tag, not the last opened one, then when I type '</'
and the editor completes it to an unwanted tag, I can edit it manually (.
The XMLSpy approach is much more pervasive since the completion somewhat
forces the document to be WF. But then again, you can do pretty much what
you want.
I'm not saying that I want everybody to use this {'</' = complete closing
tag automatically} feature. If it bothers you, turn it off. If you prefer
another system, turn it on. If you're an emacs guy, no problem. I'm not one,
that's all.
I'm not saying it is easy to find an implementation that would scale up to
multi-gigabytes XML documents. I usually don't edit XML documents that are
more than 100 kb. I have never, ever, opened anything (not just XML) of more
than 10 Mb in an editor with the intention of editing it (I did sometimes by
mistake, though, but I closed the editor ASAP).
This was just a user's request. A request for a simple feature that I would
love to have in any XML editor, but then again without forcing everybody to
use it. If it appears in Ultra Edit (together with support for WF checks),
then I'll drop XMLSpy for Ultra Edit, that's all. I like a good pragmatic
approach.
Best regards,
Nicolas
>-----Message d'origine-----
>De : Rick Jelliffe [mailto:ricko@allette.com.au]
>Envoyé : mardi 29 janvier 2002 06:31
>À : xml-dev@lists.xml.org
>Objet : Re: [xml-dev] Auto-completion in editors (RE:
>[xml-dev] ANN: XML
>Origin, the XML Editor & XSLT Debugger Released)
>
>
>From: "Paul Prescod" <paul@prescod.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>
>
|
