Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: Versioning of XML Schema and namespaces

From: "Hans Teijgeler" <hans.teijgeler@--------.-->
To: "'Michael Kay'" <mike@--------.--->, <John.Hockaday@--.---.-->, <xmlschema-dev@--.--->
Date: 5/9/2005 12:39:00 PM
Michael,

In the case I painted the schemas found in the schemalocation are normative,
and we'd rather not that prople work from local copies that get out of date.

Regards,
Hans 

-----Original Message-----
From: xmlschema-dev-request@w... [mailto:xmlschema-dev-request@w...] On
Behalf Of Michael Kay
Sent: maandag 9 mei 2005 10:10
To: John.Hockaday@g...; xmlschema-dev@w...
Cc: ":www-xml-schema-comments"@w3.org
Subject: RE: Versioning of XML Schema and namespaces


Personally I think the combination of a namespace and a version attribute in
the document element is a better way of asserting conformance to a
particular version of an external standard than use of a schemaLocation. The
reason for that is that the semantics of xsi:schemaLocation as defined in
the XML Schema specification don't say it's an assertion about conformance,
they say it's a hint about where to find a schema to use for validation.  I
think it's a mistake to overlay different semantics onto an attribute
outside your control; and more practically, using this attribute as a
conformance assertion prevents people using it to point to a local copy of a
schema.

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

> -----Original Message-----
> From: John.Hockaday@g... [mailto:John.Hockaday@g...]
> Sent: 09 May 2005 01:24
> To: mike@s...; xmlschema-dev@w...
> Cc: ":www-xml-schema-comments"@w3.org
> Subject: RE: Versioning of XML Schema and namespaces
> 
> 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 ekimber@i... Mon May 09 14:48:10 2005
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1DV9YI-0001v6-Ny
	fo


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