W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2007

Re: Schema 1.1: xs:anyEnumeration considered?

From: Pete Cordell <petexmldev@tech-know-ware.com>
Date: Tue, 20 Mar 2007 16:36:59 -0000
Message-ID: <014a01c76b11$5d8e2040$c900a8c0@Codalogic>
To: <d_a_carver@yahoo.com>
Cc: "David Ezell" <David_E3@VERIFONE.com>, <xmlschema-dev@w3.org>

Original Message From: "David Carver" <kingargyle@...>

Thanks for your comments Dave.

> First, I'll state that I'm just a consumer of the spec, so I'm not a work 
> group member, but I do work for a B2B standards organization that use 
> schema extensively.
>>
>> And, I think only a parent could think that the union trick is not ugly 
>> :-)
>>
> Actually, it has it's good and bad points, but I don't necessarily think 
> it is an ugly trick, just one that is not published enough or written 
> about enough.   From my aspect, it takes educating my users about the 
> extensibility and the various ways that it can be done.

Doesn't the fact the users need educating more about it just prove that it 
is an insiders trick?

>> ...
> I deal with people that don't care how the schema is created, as long as 
> it doesn't affect there system and break their code.   The less they have 
> to deal with it the better, ...

I think this is the opinion of a lot of developers.  Hence the need for no 
surprises.

> ...it's why they have our organization create the schemas that they use.

It may be appropriate to get specialists in to define large, industry wide 
schemas, but I don't think it should be a requirement for smaller 
applications of schema.  In some cases it may just be as simple as an 
application's config data with a few dozen values!

One of the primary use-cases I'm interested is in using schema in emerging 
protocols having extensibilitys equivalent to HTTP, SMTP and (VoIP's) SIP. 
These are highly extensible protocols, developed by people (the IETF) who 
are intimately familiar with extensibility issues.

> The problem with extensibility is that it DOES create interoperability 
> problems, no matter how you try to control it.   Once it is extensible, 
> then you immediately have interoperability problems when somebody does a 
> one off implementation of a schema.

I would be interested to hear how you do your versioning.  Do you just 
re-issue a new schema in a new target namespace?

> Yes, you can do must understand and must ignore type logic, but experience 
> has shown me that people don't do this.   They bind to the schema that 
> they are given, and if that deviates from the industry standard schema, 
> they don't know or care.

I agree that, like security, people don't give versioning enough 
consideration.  To be secure something needs to be designed from the 
ground-up with security in mind.  Equally, to be versionable, applications 
needs to be designed from the ground-up with versioning in mind.  Sadly, 
only education can fix that!

> Extensibility has it's place, and with enumerations, I think the way it 
> works now for enumerations is "good enough", not perfect but it gets the 
> job done.   Anything else from my experience makes more interoperability 
> problems not less.

Is that a case of "good enough" for you?  I certainly wouldn't force people 
to make their schemas extensible (although maybe I should be saying 
versionable), and it's very easy to create such schemas today.  But not all 
usages of schema are the same.  What I've heard so far is, because it's not 
right for me, you can't have it!  This doesn't sound reasonable to me!

Thanks again,

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx/
http://www.codalogic.com/lmx/
=============================================
Received on Tuesday, 20 March 2007 17:01:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:41 UTC