[
Lists Home |
Date Index |
Thread Index
]
On Sun, 2 Mar 2003 21:17:59 +1100, Rick Jelliffe <ricko@allette.com.au>
wrote:
>
> Is this a challenge? What editors are you thinking about, and how do
> they break the downstream processes?
>
> Is this editors which do/don't collapse everything to a single line or
> what?
> How do we make sure our editors are not sinister forces for unexpected
> evil in the production chain, as Sean seems to suggest?
My experience is a bit out of date, but what Sean says resonates with my
experience trying to work with, for example, XMetaL, Epic, and XML Spy on
the same instances, and looking at the XML support in Office 2003 Beta1.
I'll take a stab:
Different editors require various bits of PI, Doctype, or namespace voodoo
in the XML instance for all their bells and whistles to work. They don't
know about or necessarily respect each other's, so ugly things happen when
one moves from one editor to another.
They support different standards for stylesheets -- FOSI, CSS, XSLT, and
sometimes proprietary stuff too.
They support different standards for schemas -- XML DTD, SGML DTD, W3C
Schema, .... not to mention RELAX NG, Examplatron, etc.
They have various private filetypes or registry entries that can get out of
synch with changes to the schema or stylesheet from a different
environment.
And there's the famous "do/don't collapse everything to a single line." I
had the rather humiliating experience <grin> when I worked for Arbortext of
having other DOM WG editors nag me into using emacs rather than Adept to
edit the DOM spec because its whitespace handling (or lack thereof) made
the XML it produced difficult to work with in a raw text editor. That may
or may not be an issue with Epic these days, I don't know.
Again, the current situation might be better than when I last got bitten by
this stuff. The ideal way for editor vendors to avoid evil is by
supporting all the relevant standards in a correct and interoperable way,
and not relying on PIs, external files, registry entries. BUT ...
How would they get rid of their legacy proprietary cruft and keep their
current customers happy? How would thay maintain bug for bug compatibility
with the various other tools that their customers use? What's the business
value of allocating their best programmers to unravelling the mysteries of
the various specs that essentially no one supports in a fully interoperable
way? How do they handle the imponderables, such as which of the contending
models for how namespace information is associated with elements as text
and declarations move around in a document?
Beats the hell outta me!
|
