W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2004

Comments on the Charter of the XML Schema Working Group

From: <John.Hockaday@ga.gov.au>
Date: 31 Aug 2004 16:09:41 -0600
Message-ID: <E97B4331B4C19943B69A80E15DE45C260135557B@mail1.agso.gov.au>
To: <www-xml-schema-comments@w3.org>
Cc: <creediii@mindspring.com>


I commend the "Charter of the XML Schema Working Group" for looking into the
W3C XML Schema specification.  I have had many problems with validating XML
Schemas for the following reasons:

1.  There are ambiguities within the XML Schemas. Some parsers, eg. XMLSpy,
disregard these ambiguities, and others, eg. Xerces, do not.  I have found
that XML Schemas developed on XMLSpy, eg. GML, do not validate on other
parsers.  This means that when one tries to validate an XML Document Instance
defined by XML Schemas one will never get a validation because of the
ambiguities on the XML Schemas themselves.  

This should be addressed in version 1.1 so that there are *no* ambiguities. I
hope that this is a high priority on the "Charter of the XML Schema Working
Group".  Otherwise, I will be using RELAXNG or some other XSD that does not
have ambiguities and I will suggest this to the rest of Australia.

2. The schemalocation attribute does not have a method of identifying the
location of local copies of the XML Schema using something like Oasis
Catalogues or PUBLIC identifiers.  DTDs do allow this. Yet when I use XML
Schemas I have to keep all my XML Schema in the exact directory structure as
the developers when I'm trying to validate supplied XML Schema and XML
Document instances.  

For example, ISO 19139 XML Schema calls the GML XML Schemas however, I have
my GML XML Schemas already stored in a different directory structure to those
in the supplied ISO 19139 XML Schemas. This means that I either have to
change the ISO 19139 XML Schemas, something that seems atrocious to me, or
move my GML XML Schema into a directory structure similar to those as defined
in the ISO 19139 XML Schema.  XSDs should not need to be edited!  Especially
if it is just to reference other XML Schemas.

Furthermore, if I am trying to validate a supplied XML Document Instance that
relatively refers to the XML Schema, them I must either change the XML
Document Instance or store it in a directory path that is the same as that
identified in the XML Document Instance.  XML Document Instances should not
be edited to validate them.

I validate over 30,000 XML Document Instances each quarter that I download
from distributed sites all around Australia.  Currently I can automatically
validate these instances in a few days because they use DTDs and I can use
Oasis Catalogue files to reference the local copies of those DTDs on my
system.  I am *not* going to edit 30,000 XML Document Instances if these are
referencing XML Schemas.  I am also *not* going to allow my software to go
out onto the internet to access XML Schemas to which the XML Document
Instances refer.  This will not only use up valuable bandwidth but also run
up the cost of our ISP service.

There needs to be some sort of PUBLIC identifier and Oasis Catalogue system
within the XML Schema specification so that one can identify on his or her
system where the validators can find the local copies of the XML Schemas and
so that one doesn't have to edit his or her XML Schemas and XML Document
Instances to find the location of the relative XML Schemas.

I certainly hope that this is a *very* high priority on the "Charter of the
XML Schema Working Group" as it is a major problem for the implementation of
XML Schemas and their XML Document Instances.

I commend the "Charter of the XML Schema Working Group" for looking into the
W3C XML Schema specifications especially if they fix the above mentioned
problems.  Otherwise I will be using RELAXNG or some other XSD specification
that doesn't have these problems.

Thank you for your time in reading and considering these comments.

John Hockaday
Geoscience Australia
GPO Box 378
Canberra ACT 2601
(02) 6249 9735
Received on Tuesday, 31 August 2004 22:10:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:02 UTC