Non Sucking YAML parser
robin.berjon at expway.fr
Wed Sep 13 16:40:20 BST 2006
On Sep 13, 2006, at 17:20, Mark Overmeer wrote:
> If you pick XML, you probably want to write a specification for
> your data structures. Then, you may consider to use XML schema's.
> They are more verbose than useful, and require some study.
> However, it
> is widely accepted in the business world.
I would recommend the exact opposite: if you have any chance of
avoiding having to use XML Schema anywhere, then run away like hell.
It is by far the worst specification ever produced by the W3C. It is
a world of pain.
The "wide acceptance" in the business world is largely limited to
either data binding for very limited enterprise scenarios (where the
schemata are machine generated based on Java or .NET stubs) or to
wanking about schemata that are never used in practice because
they're so painful. A Belgian study released last year showed that
*70%* of those schemata are not even valid as per the spec — you can
imagine how much that means they're actually getting used.
> When you choose to create a schema for your data-exchange, you may
> a look at my new module XML::Compile. It hides *all* XML processing
> from your program, is very fast, validating, processes types strictly,
> and does name-spaces correctly. Written because the existing modules
> were to sloppy and slow for my taste.
That's not a bad idea at all, but you're up for difficult times I'm
afraid. How do you plan on handling the majority of schemata that are
broken? Also, it is extremely common (if not simply the rule) that
instances won't always validate, sometimes simply because over a
large production array you will have six or seven different versions
of the vocabulary in use, and therefore at least as many variants on
the schema. How do you handle deviance?
Senior Research Scientist
More information about the london.pm