[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Namespace
Gary A Ham wrote: > we must accommodate de facto standards with > significant market share, or we must have > the market power ourselves to kill them. This is true, but it has little to do with the point I was making in the message to which you are responding. I was not speaking to the issue of *whether* de facto standards should be "accommodated". Rather, I was speaking about *how* they should be accommodated. (i.e. It should be done explicitly, rather than in silence or by omission.) If there is some "de facto" standard which CAP should accommodate, then hopefully a precise description of that de facto standard can be identified and referenced as a normative reference from the CAP specification. If such a description doesn't exist, then the CAP specification should describe the "de facto standard" that it is incorporating. In any case, there must be a clearly written description of what CAP is in order for it to be useful. Thus, in the namespace example, if CAP definers insist on supporting extensions to XML Schema such as named local simpleTypes, then CAP should explicitly define what those extensions are. At this time, however, the CAP schema incorporates attributes which are explicitly prohibited by the XML Schema standard and there is no definition of the meaning of the extensions. Successful interop via the CAP specification and schema relies on disparate parties recognizing the undocumented bugs in the CAP Schema and then adopting similar, compatible policies for fixing the bugs. Additionally, interop relies on having the people who "fix" the bugs doing so in such a way that the fixes are compatible with the bugs in those schema processors that wrongly accept the CAP Schema as valid XML Schema. All of this, of course, must be done without any direct communications between any of the "bug fixers" or "users of buggy processors". Somehow, it seems to me that it would have been just a little easier to either produce a "proper" XML Schema or to explicitly document the CAP extensions to XML Schema... bob wyman -----Original Message----- From: Ham, Gary A [mailto:hamg@BATTELLE.ORG] Sent: Wednesday, March 31, 2004 2:11 PM To: bob@wyman.us; Rex Brooks; R. Allen Wyke; Art Botterell Cc: Kon Wilms; Emergency TC Subject: RE: [emergency] Namespace I would like to make only one comment here. Purists that we would all like to be, we must still remember that "If Nobody Uses It, It Ain't a Standard." (Crosstalk June 1998) I.e, we must accommodate de facto standards with significant market share, or we must have the market power ourselves to kill them. You guys decide. Respectfully, Gary -----Original Message----- From: Bob Wyman [mailto:bob@wyman.us] Sent: Wednesday, March 31, 2004 12:25 PM To: 'Rex Brooks'; 'R. Allen Wyke'; 'Art Botterell' Cc: 'Kon Wilms'; 'Emergency TC'; Ham, Gary A Subject: RE: [emergency] Namespace Rex Brooks wrote: > A standard XML Schema Validation Service would be a fine > help to start, but it would have to be verified as validating > standards that demonstrably work successfully with the major web > stacks, but most especially with the stacks that represent the vast > majority of market share on the web, Apache with ~62-67% and Microsoft > ~22-27%: No, No, No! This would be good thinking if you were writing a product, but this isn't a product. CAP is a *Standard*! It requires a different kind of thinking. When writing a standard you must, as Len Bullard said, be "tediously correct." This means that your normative clauses *must* conform to the normative clauses of the standards that you reference. Thus, if XML Schema says that local simpleTypes MUST NOT have "name" attributes, then CAP MUST NOT be defined to use them even if *no* software exists that can handle local simpleTypes without name attributes. The reason for this is that standards "live forever" while products are ephemeral. Standards define laws. Products do not. Products come and go and change their capabilities from release to release. There is always a tension between products and standards. However, those who write standards best serve their constituencies by writing their standards in the most unambiguous form possible. This means that you must write every sentence with the precision that a lawyer would and you must read every clause of your referenced standards as though they were law. Only by following this method can you hope to have consistent interpretations of standards. In the rare case that it is necessary to depart from an existing standard, the correct way to do this is to either produce a "profile" of the inadequate standard or, if the issue is product specific, produce a non-normative implementation guide that unambiguously explains how the standard is to be interpreted by users of the product. You could, for instance, produce a profile that defined a "CAP/XML Schema Language" which extended the XML Schema syntax to include "name" attributes on local simpleTypes. However, doing this would mean that standard XML Schema processors would not be able to work with the CAP/XML Schema. This would also mean, of course, that the Emergency TC would now "own" a standard with all the complexity of XML Schema... Not a good thing. Doing something like this is rarely the right thing to do. The more reasonable approach is to recognize that some set of processors that have *bugs* that prevent them from processing Schemas that conform to the XML Schema of Schemas. In this case, if Axis is the offending processor, one could write a non-normative implementation guide that defined exactly how the properly defined normative XML Schema should be modified to address the bugs and limitations of the offending processor. This might be done by providing a non-normative restatement of the CAP Schema or by producing something like an XSL template that deterministically transforms the normative schema to one that the offending processor can process. However, the XML Schema conformant version of the CAP schema must always be the single normative expression of CAP. Sometimes, if you're lucky, you'll discover that a standard on which you are dependent offers more than one way to accomplish some purpose. And, you'll discover that popular or important processors of the format are capable of handling one method but not the other. In this case, it is sometimes appropriate to allow this knowledge of the limitations of existing processors to push you to prefer one method over the other. As long as there is an alternative that doesn't compromise your ability to express your standard clearly and unambiguously, it is ok to choose the alternative that is more supported. However, this is *not* a slippery slope that leads to adopting non-conforming syntax. You MUST stop this accommodation of broken processors at the moment that such accommodation either compromises the clarity of expression in your standard or at the point where further accommodation requires violation of the referenced standard. Naturally, in the context of product building, not standards defining, these rules are completely different. When building a product, one typically tries to be as accommodating as possible. But, we're not building a product here... bob wyman
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]