Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The subsetting has begun
 On Sun, 2 Mar 2003 21:17:59 +1100, Rick Jelliffe <ricko@a...> 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! 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
