Re: [xml-dev] provocations and realities (was Re: Fwd: [xml-dev]Not usin

["Simon St.Laurent" <simonstl@simonstl.com>]

On 4/8/13 2:24 PM, Fraser Goffin wrote:
>> I am not entirely surprised that people who've spent their working lives
>> with schemas and similar tools have a hard time seeing the costs.
>
> Well that doesn't apply to me. By and large I use XML schema fairly
> infrequently and am no greate supporter of its over complexity and
> lack of expressiveness. That said, when it fits the problem space I'm
> not frightened of picking it up.

Of course it doesn't apply to you.  How could it?  I'm sure reader after 
reader is saying the same thing.  That's fine - this is not an easy 
message to digest.

> I seems like the problem you're having is understanding that there are
> plenty of us who use all kinds of techniques and approaches but not at
> the extremes.

No, I'm afraid that that is not the case.  After a decade and a half of 
working in this field, I'm quite certain that the XML community is full 
of flexible people who choose their tools based on their projects.  Even 
the most schema-centric developers I've encountered have occasionally 
played with 'free' markup, and I was reviewing a schema this morning.

Unfortunately, I think that markup culture was cursed with some ugly 
tendencies from the outset - SGML days, probably earlier - and those 
approaches are baked deeply into the culture.  I took them as a given 
when I arrived in markup, because that just seemed to be The Way. It wasn't.

I have been delighted that this conversation turned up a few people who 
really just don't use schemas of any kind, and their experiences added 
to my conviction that markup works just fine without schemas.

(My experience with the JSON community had already led to the same 
conclusion.)

> I am reminded about some of the design and development principles that
> we often like to apply to software engineering problems. As we all
> come to realise its not that all of these need to be 'turned up to the
> max', it not even the case that they are all 'complementary', it is in
> understanding that we need to balance the oftentimes conflicting aims
> to find solution that finds emphasis in our specific problem space.

Again, I'm not necessarily concerned about "to the max", though I was 
amused when I found this after Roger's question about parsers:

<http://www.xmlbooster.com/>

Native code generation!  Forget all about those pesky XML APIs! 
Supports a wide variety of languages, including... COBOL!

You don't have to go nearly that far for schema-centricity to freeze 
your conversations, lock out new possibilities, and add brittleness to 
your systems.  Even locking down a vocabulary without a formal schema, 
or with a nominal schema, can impose those same costs by convincing 
people that the vocabulary is not theirs to extend.

(That would be the story of HTML for far too long...)

> I always sigh in dismay

You're welcome to sigh all you want, as long as it helps you clear the 
old air from your lungs.

> when arguments are presented in these very 'on
> or off' terms, and whilst illiciting response by being confrontational
> can be incredibly useful, it is also just the precursor towards
> understanding the picture from other perspectives that may be
> irrelevant in our current domain, but not in everyone else's.

After fifteen years of propaganda, some even written by me, I'm 
reasonably certain that I've heard about all the great things that 
schemas can accomplish in a wide variety of domains.

It's not about domains, and it's not about the weakness of the tools. 
It's about how we structure our conversations about data, which voices 
we are willing to listen to, and how those conversations evolve over time.

It does require restructuring the way our code processes markup and the 
ways we write code, so it's not easy - but it does offer the flexibility 
we've been promised since the punch cards disappeared.

(And yes, I'm writing a more coherent telling of the whole story.  Woke 
up at 2am for some reason to make a solid start... and I'll edit it in 
daylight hours to make sure it's genuinely coherent.)

Thanks,
-- 
Simon St.Laurent
http://simonstl.com/