Non Sucking YAML parser

[Robin Berjon]

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  
> take
> 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?

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/