[Bug 3251] need for precisionDecimal / how to introduce primitives

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3251





------- Comment #8 from noah_mendelsohn@us.ibm.com  2008-01-04 15:42 -------
I think the deep question here is about what is considered conforming.

As far as I can tell, everything that's proposed is possible today except for
the new XSDL syntax.  Does that syntax do anything other than serve as a cross
check or early warning that the type is indeed believed to be primitive?  The
implementation is surely built into the validator either way.  

Today ship a validator that includes new primitive types, I must document it as
nonconforming.  I infer that the proposed change (other than the syntax) would
be to consider such processors to be fully conforming, I.e. as conforming as
they would have been had they not supported the new primitive(s).

I remain very reluctant to "bless" such processors as conforming.  I think it
will lead to confusion.  Worse, I worry that certain suppliers of schema
software will widely deploy software that depends on types that are in some
sense competitive with the ones we already have (perhaps tied into their
middleware runtimes), and thus divide the schema community.  

So, I prefer to retain some distinction in the terminology about conformance.  
I want to be able to say that processors that use extension types are either
not conforming, or that they are conforming in some much more limited way (not
sure whether I could endorse that latter approach, but I'm very glad to discuss
it).    This way if someone calls up and says: "gee, how come your processor
couldn't handle my schema with the "GiantCorpInteger" type?" I can say "Ah, I
see, you didn't restrict yourself to features that are fully conforming." (or
whatever).

Maybe or maybe not our RQ-144 mechanisms would give us some leverage for
tackling this.  

So, my counter proposal (which I'm not quite ready to endorse but certainly
ready to discuss a bit) would be:  
a) No new syntax.  Your schema just uses the type like any other.  If it's
built into the processor with a base type of anyAtomic, so be it.
b) We document (I.e. name) a core level of conformance for processors that do
not add such types, and note that interoperability is reduced insofar as users
chose to refer to types that are neither provided with XSD nor declared using
the facet mechanisms of XSD.

Crucially:  I am not happy about moving xs:precisionDecimal into the class of
such optional types. I think that every processor that implements Schema 1.1
should implement precisionDecimal.

Noah

Noah

Received on Friday, 4 January 2008 15:42:12 UTC