Re: [xml-dev] JSON, tides and XML

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

On 4/28/13 9:15 PM, w3c@drrw.info wrote:
> You see - I told you I'm first to do things different - why the heck
> would you think I'm using something as ghastly as XSD schema to do
> this?! ; -)

Instead of schema you seem to be using something much more comprehensive 
that, though I'll have to study it more closely, actually looks much worse.

The press release of a wikipedia article definitely has me running for 
the hills:

<http://en.wikipedia.org/wiki/OASIS_CAM>

This doesn't help much either, though perhaps it's written for the 
schema-centric:

<http://sourceforge.net/apps/mediawiki/camprocessor/index.php?title=Main_Page>

>>>> "Much of my point in this recent conversation - the piece that really
> seems to make people angry, in any case - is that creating such
> standards is a bad idea, and schema a particularly dangerous enabler. As
> a result, that claim doesn't have much positive effect on me." <<<
>
> Completely agree!

I'm pretty certain you didn't read the first sentence, or at least if 
you did, you interpreted it in some way that spares CAM for no apparent 
reason.

> All that XSD schema does is tell you the millions of possible
> permutations that you may encounter.

Which is bad enough, but yes...

> Instead the CAM template hones in on the WYSIWYG view of the exchange -
> complete with content use rules - code lists - SQL lookups - and
> annotations for content hinting and DBmapping.  Plus most important -
> you can have dynamic content components - essential for versioning - or
> dealing with nuances from 500 trading partners foibles in their
> application systems.

How much of that is shared across partners?  Dynamic content components 
sound like the escape hatch need to make such madness flexible enough to 
work for a while, but so far as I can tell that's something to do with 
generating structure from SQL.

> Structure + Content + Rules + Annotations + Components + Policy in one
> tidy XML package = CAM template.
>
> While we may never get to the Nirvana of complete automation - its a
> huge jump start.

Complete automation is not Nirvana.  That's hell.

> And because we use Dictionaries of XML components in the designer mode -
> you can assemble and reuse for a domain.  So defining your standard
> around those reusable assets makes much more sense - this is truly what
> people think intuitively of as they look conceptually at their data
> exchange needs - Person, Address, Order Item, Customer, Patient,
> Student, and so on.

After all, it would be a huge headache for people to create vocabularies 
structured around what they actually say.

> But we can generate an XSD schema if you still need it for your tooling
> - e.g. JAXB binding or Form tool designer or JSON tool.  All driven with
> by the power of XSLT and XPath over your XML definitions.
>
> I really do not need to reinvent all this rich capability for JSON that
> does not have it.

No, you don't.  On the bright side, you've gone so far in the wrong 
direction that hopefully you won't have the JSON folks knocking on your 
door very often.

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