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] Note from the Troll

[ Lists Home | Date Index | Thread Index ]

Amelia A Lewis wrote:
>>1) XML Tools suck - they're little more than syntax coloring editors.
> On the whole, I tend to agree that tools aren't up to par as yet.  But
> ... different people need to do different things.

And the hard bit is figuring out what people really need. I know it took 
me some time to figure out what it was that I miss in XML editors. My 
grief is that most of those that do offer some help are focussed on 
schema-based approaches, which is great when you're editing documents 
that happen to have a schema, which in my case is less than 5% of the 
time. Most of the XML editing I do either has requirements very specific 
to a vocabulary (XSLT, XML Schema) or has to do with vocabularies which 
I later transform into their "standard" and verbose counterparts (eg 
DocBook). In such cases all I'd want would be to specify a CSS sheet -- 
perhaps with a limited number of extensions -- and get a nice wysiwyg IU 
for my document.

You may wish to have a look at Topologi (http://www.topologi.com/) which 
has very interesting features.

>>XSLT files are maintainable with the same level of ease as densely 
>>written perl.  Developers asked to modify them routinely rewrite them 
>>because they can't figure out what the last guy was doing.
> Hmm.  I haven't encountered that one.  I think some of the more
> web-oriented here have reported similar things, though (my work doesn't
> bring me into contact with that segment).  So the transform sets that
> I've seen in use tend to be much more maintainable.

I think that's due to an ensemble of factors common to both languages. 
One of them is the multiplicity of immediate solutions to a problem that 
solve it equally efficiently but are unequally adapted. How many 
XSLT-using folks know when best to use call-template, apply-template, 
apply-template with select, apply-imports, or for-each (or even 
value-of, choose, etc... they can often be interchanged)? Instead of 
trying to reach for the best tool, I've often seen people use whatever 
first comes to their mind. I guess that's where the market for B&D 
languages is :)

Add to that the fact that most people will only learn what they need to 
get their first hack done and then consider they know the language, and 
you indeed end up with horrible sheets that you have to throw away 
everytime you modify them. Come to think of it, how many times have you 
seen XSLT modes being used, and yet they are so useful.

Large XSLT sheets can be very much maintainable, so long as every time 
you start typing one of those elements you think twice about whether 
it's the best fit in your toolbox or not. It's worth it because I have 
yet to see a tool that does better than XSLT for tree transformations. 
I'm pretty certain anyone would positively hate to maintain the 
Java/C++/whatever code accomplishing the same tasks.

>>loved it because the thing itself is the damnedest puzzle.  It 
>>entertained and challenged their intellect to work with it.  I'm 
>>beginning to suspect the same about XML.
> *laugh*  I, for one, *hate* having the nasty little corners crop up.  I
> end up having to explain (for instance) that attributes are *not* in the
> default namespace when unadorned, even though similarly unadorned
> elements are.

Indeed... I sometimes feel some form of sick pleasure in coming up with 
solutions to problems that people have created for themselves in the XML 
world, but most of the time I share your pain. Whenever I'm asked yet 
again to explain XML Schema unqualified locals, I know it's going to be 
a bad day ;) "Smiling and wincing, smiling and wincing..."

>>7) While there is lots of heavyweight support for reading XML, there 
>>isn't any help for writing it from various other data structures.
> Hmmm.  I kinda need to think about that one, I guess.  We've been having
> go-rounds on the subject of "serialization", at work.

If you have a schema then you can probably use some form of data 
binding, though I must say I'm not too fond of that (it's ok to dump out 
some data if that data is regular enough, I find it pretty much useless 
with documents. Those tools also often lack granularity in their output, 
eg ways to insert a PI for instance). I agree that this is an area in 
which XML could use some extra smarts.

Kip Hampton's XML::Generator::PerlData is an excellent first step, 
though there's always more that can be done of course:


Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488


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

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