[
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:
http://search.cpan.org/author/KHAMPTON/XML-Generator-PerlData-0.87/PerlData.pm
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
