Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Versioning of XML Schema and namespaces

From: <John.Hockaday@--.---.-->
To: <mike@--------.--->, <xmlschema-dev@--.--->
Date: 5/9/2005 8:24:00 PM
Michael,

Thanks for your comments.  Please see below one aspect that I disagree =
with.

Thanks to you all for being patient and contributing to this discussion.


John

> -----Original Message-----
> From: Michael Kay [mailto:mike@s...] 
> Sent: Friday, 6 May 2005 8:26 PM
> To: Hockaday John; xmlschema-dev@w...
> Cc: ":www-xml-schema-comments"@w3.org
> Subject: RE: Versioning of XML Schema and namespaces
> 
> 
> ....
> 
> I wouldn't expect the instance document to contain a schemaLocation
> attribute, or if it does, I wouldn't expect a recipient to 
> trust it when
> doing validation. If say the sender has decided to leave out 
> some mandatory
> elements, and to create a local copy of the schema that makes 
> them optional,
> you as the recipient don't want validation to succeed.
> 

The metadata gateway that I manage will be able to search metadata of
multiple types.  For example; 
ANZLIC version 2 defined by 
http://www.environment.gov.au/net/dtd/anzmeta-1.3.dtd , 
extensions to this standard such as 
http://www.indexgeo.net/dtd/anzmeta-resource-v11.dtd and
http://www.gso.qld.gov.au/qsiis/dtd/qsiis-1.3.dtd 
or ISO 19139 metadata records including extensions of that standard, =
which
are yet to be defined.

If I download an XML metadata record (document instance) I don't know =
what
standard I should validate it against unless there is a DOCTYPE or
schemaLocation declaration.  I therefore can't validate that document =
without
this information.  I believe that *every* XML document instance should =
have
either a DOCTYPE or a schemaLocation so that anyone who wants to look at =
this
instance knows with what XSD it complies.  One may not wish to validate =
the
document but if one wants to use the document then he or she needs to =
know
what this document is about.  That can only be rigorously identified by =
a
DOCTYPE or schemaLocation declaration.

Furthermore, I agree that if a "mandatory" element in an extension of =
the ISO
19139 metadata standard has been redefined as "optional" then validation
should ignore that change. However, by definition of the extensibility =
of the
ISO 19115 metadata standard, an "optional" ISO 19139 element can be made
"mandatory" in an extension of that XSD for an organisation's or =
country's
need.  Therefore, one *must* use that extension when validating an XML
document instance of that XSD type to check that it meets those needs.  =
The
only way I know of to identify that extension is from a schemaLocation
declaration and therefore is it necessary to validate that XML document
instance.

Public identifiers were great.  There was only the need for one DOCTYPE
declaration in an XML document instance.  It was the inclusion of the
original DTD in the DTD identified by the DOCTYPE that defined the =
extension.
It wasn't necessary to have the original DTD identified in the XML =
document
instance.

However, and I'm not sure about this, it seems that if one extends a W3C =
XML
Schema then one needs to not only identify the new XSD via a namespace =
but
one also needs to include the original XSD that has been extended.  If =
this
is so then XML document instances can become *very* messy when there is =
an
extension of an extension of an extension etc..  

Thanks for your time.

J.H.

> Michael Kay
> http://www.saxonica.com/
> 
> 
> 

From mike@s... Mon May 09 08:10:16 2005
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1DV3L


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent