[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The subsetting has begun

emacs collapse
On Sun, 2 Mar 2003 21:17:59 +1100, Rick Jelliffe <ricko@a...> 

> 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!


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.