Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


SV: rules for handling document elements not in the target namesp ace?

From: Bryan Rasmussen <brs@----.-->
To: "'xmlschema-dev@--.---'" <-------------@--.--->
Date: 4/4/2005 2:56:00 PM
I guess my earlier email must not have been clear, or at least I hope it was
lack of clarity and not just a question so stupid as to be unanswerable
without emotional pain, so here is a second attempt:

given the following schema:

<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="http://rep.oio.dk/xkom.dk/xml/schemas/2004/02/02/"
xmlns:xkom="http://rep.oio.dk/xkom.dk/xml/schemas/2004/02/02/"
xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
	<element name="EmailAddressIdentifier"
type="xkom:EmailAddressIdentifierType">
		<annotation>
			<documentation
source="http://rep.oio.dk/xkom.dk/xml/schemas/2004/02/02/xkom_emailaddressid
entifier.xsd.meta.xml"/>
		</annotation>
	</element>
	<simpleType name="EmailAddressIdentifierType">
		<restriction base="token">
			<pattern
value="([^&gt;\(\)\[\]\\,;:@\s]{1,90}@[^&gt;@]{1,64})"/>
</restriction>
	</simpleType>
</schema>

and the following instance

<doc xmlns:xkom="http://rep.oio.dk/xkom.dk/xml/schemas/2004/02/02/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://rep.oio.dk/xkom.dk/xml/schemas/2004/02/02/
email.xsd" 
>
<xkom:EmailAddressIdentifier>bry@i...</xkom:EmailAddressIdentifier>
<xkom:EmailAddressIdentifier>bry@i...</xkom:EmailAddressIdentifier>
<xkom:EmailAddressIdentifier>bry@i...</xkom:EmailAddressIdentifier>
<xkom:EmailAddressIdentifier>bry@i...</xkom:EmailAddressIdentifier>

</doc>

is that instance valid?

I thought it should be, according to XSV and msxml's SchemaCache it is okay,
XSV in this case defaults to a lax processing, a coworker says he remembers
this being optional according to the spec. Can anybody reference me to the
part where this is defined as optional, or if not where it is explicitly
allowed or disallowed?



-----Oprindelig meddelelse-----
Fra: Bryan Rasmussen 
Sendt: 31. marts 2005 16:00
Til: 'xmlschema-dev@w...'
Emne: rules for handling document elements not in the target namespace?





Hi, I have a schema in namespace X that validates one global element, in
order to test that element I went ahead and put various versions of the
element in a document with a document element in a different namespace, most
processors reacted fine with that and told me that my proper examples were
correct and my bad examples were incorrect. 
XMLSPY however got upset that the document element was not validated in my
schema.

as a second test I then created an instance consisting only of a document
element not in the target namespace of the schema which XMLSPY also reported
as being invalid because of the document element not being validated by the
schema. 

A co-worker said that this was because doing so was optional by the spec, by
my memory this was not one of the optional sections. I've looked but of
course the spec is rather large, can someone point me to the optional part
of the spec on this matter or give me some backup on its not being optional
if indeed it isn't. 

From mike@s... Mon Apr 04 12:10:17 2005
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.org with esmtp (Exi


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