OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[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]