XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Backward and forward compatible schemas ... Relax NG --> Yes ... XML Schema --> No

That's true and that means the standard has to have a means to say 'this is dynamic, ie, functional and you will want to put a measuring stick and measurer here'..  This is what ANY does in some respect:  note the presence of a negotiation by location.

 

Good point.

 

len

 

-----Original Message-----
From: Fraser Goffin [mailto:goffinf@googlemail.com]
Sent: Wednesday, August 29, 2007 8:32 AM
To: Len Bullard
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Backward and forward compatible schemas ... Relax NG --> Yes ... XML Schema --> No

 

Len,

 

> Everywhere one finds a wildcard, there is an unconstrained decision list and that means

> there is no static consensus.   It might be a good idea to push that off into its own space

> and work out why this function isn't converging.
 

Yes that can be true. However in some important cases there doesn't need to be consensus, the wildcard is the agreed location for private data to be carried within the body of the public standard. I don't want the standards body to legislate on what should be in this area, thats a matter between me and my trading partners, but I *do* want them to provide the location so that I can respect and work within the spirit of the standard and at the same time be unconstrained in my business model. My company has no desire to become a standards body with all that that entails, so we are strongly motivated to use the standard vocabulary agreed by the industry as a whole, but not at the expense of doing business.

 

Fraser.


 

On 29/08/2007, Len Bullard <cbullard@hiwaay.net> wrote:

Another change is to break up the industry standards into smaller independent pieces.   It would be interesting to see a complexity assessment model of various industry standards and see what the local rate of change is and for what kinds of information.   It's easier to blame the process or the mammals manning the helms and sometimes that is right, but it might also be that the wrong tool is being applied or the information is dynamic by nature (somewhere a feedback loop is cycling chaotically).

 

Everywhere one finds a wildcard, there is an unconstrained decision list and that means there is no static consensus.   It might be a good idea to push that off into its own space and work out why this function isn't converging.

 

len

 


From: Fraser Goffin [mailto: goffinf@googlemail.com]

 

> The industry standards need to move at a faster pace

 

Agree entirely, however the motivations of some are to constrain change, and concensus is typically hard to acheive. An industry standards body also often finds itself trapped between the competing interests of its members and ... well I could go on, but we all understand the problem.

 

My motivation is to encourage the standards body to allow for private extensions in schemata. There is no reason why a standards body needs or should be in the middle of trading partner agreements which manifest themselves in data exchanges private to those individual organisations. The concern often expressed is that private extension degenerates the standard, but the reality is, without the ability to accomodate change (both breaking an non breaking) and allowing participants to adopt change at a time of their own choosing, then a standard has no future. Natural market pressures will drive adoption. Extensibility (call it forwards/backwards compatibility if you like) is certainly part of the solution, and, as you point out, careful selction of what should be mandatory and optional, and implementation of various validation schemes that support the level of compatibility/tolerance that an individual or pair of trading partners require, and .... well you get the picture.

 

 

 

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS