W3C home > Mailing lists > Public > xmlschema-dev@w3.org > December 2004

Re: Using non-native attributes

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 10 Dec 2004 09:42:00 -0500
To: Craig Salter <csalter@ca.ibm.com>
Cc: xmlschema-dev@w3.org
Message-ID: <OF18962A34.7E4F33DC-ON85256F66.00507133@lotus.com>

Craig Salter writes:

>> The XML validator in WSAD is based on Xerces  2.0.0 and hence we 
inherit one of their bugs related to process schema for schema. 

Actually, I think it's a bit more subtle than that.  The schema 
recommendation makes clear that declarations for the built in simple types 
are present by definition in every schema, without reference to the schema 
for schemas [1]:

"Similarly, simple type definitions for all the built-in derived datatypes 
(see the Derived Datatypes section of [XML Schemas: Datatypes]) are 
present by definition in every schema, with properties as specified in 
[XML Schemas: Datatypes] and as represented in XML in Schema for Schemas 
(normative) (žA)."

In fact, the builtin primitives are conjured up "magically".  Just as you 
cannot define your own java.lang.string in Java, you cannot define your 
own xsd:string in schema. 

For better or worse, the schema for schemas contains place holder 
definitions for these built in types, and therefore the schema for schemas 
as published is not a legal XML schema document!  So, the original 
versions of Xerces were correct in rejecting it.  As it turns out, of 
course, there are good uses for being able to use the schema for schemas 
to get at the other definitions it provides.  My impression is that 
Xerces, like some other processors, was updated to run in a mode where it 
ignored the definitions of the built in types in the specific case where 
they came from the schema for schemas, making it useful for import after 

So, I think the bottom line is that WSAD did not "inherit a bug".  Rather, 
it relied at first on a conforming version of Xerces that made it 
impossible to do what users often want to do.  Later versions picked up a 
version of Xerces that can run in a looser albeit non-conforming mode, 
enabling this scenario to work after all.

FWIW:  I think we in the schema WG blew it on making the schema for 
schemas non-conforming.  I think we should have left out the definitions 
of the builtins, resulting in a schema document that was indeed conforming 
and therefore usable in validations.


[1] http://www.w3.org/TR/xmlschema-1/#d0e16395

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Craig Salter <csalter@ca.ibm.com>
Sent by: xmlschema-dev-request@w3.org
12/09/2004 04:50 PM

        To:     xmlschema-dev@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: Using non-native attributes

Hi David, 

It sounds like Priscilla has offered the same advice that I would 
concerning the addition of the schema location and the correct way to set 
the "http://apache.org/xml/properties/schema/external-schemaLocation",property in your Java code (the value of the propery must be a 
whitespace separated pair ... e.g. "namespace   location").

Even with this change you'll notice that older version of the Websphere 
Studio product (e.g. WSAD 512) will complain that the reference 
XMLSchema.xsd is not valid.  The XML validator in WSAD is based on Xerces 
2.0.0 and hence we inherit one of their bugs related to process schema for 
schema.  This bug is fixed in the most recent version of our product (now 
name Rational Application Developer) by virtue of updating to a newer 
version of xerces. 

BTW, schema editing and validating capability will soon be freely 
available in the open source Web Tools Project (http://www.eclipse.org/webtools/index.html).   We're eagerly seeking additional contributors to the project.   



Craig Salter
Rational Studio XML Web Services
Internal Mail: D3/RY6/8200 /MKM 
Phone: (905) 413-3918  TL: 969-3918 FAX: (905) 413-4920
Internet: csalter@ca.ibm.com     Notes: Craig Salter/Toronto/IBM@IBMCA
Received on Friday, 10 December 2004 14:47:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:07 UTC