- From: Pete Cordell <petexmldev@tech-know-ware.com>
- Date: Tue, 20 Mar 2007 16:36:59 -0000
- 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