OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] The subsetting has begun

[ Lists Home | Date Index | Thread Index ]

On Sun, 2 Mar 2003 21:17:59 +1100, Rick Jelliffe <ricko@allette.com.au> 

> 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 

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!


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS