By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,750 Members | 1,456 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,750 IT Pros & Developers. It's quick & easy.

XMLSPY bug? Patterns at different derivation steps getting OR'ed instead of AND'ed.

P: n/a
I received a file from a business partner. I ran it through XercesJ and it
choked on the following element:

<wcb-case-number>0</wcb-case-number>

To debug this issue, I loaded it into XMLSPY and hit validate...it passed.
Here are the related type/element definitions:

// Redefine built-in string type to limit range of characters, mostly
// to eliminate undesirable white space (tab, cr, lf, etc.)
<xs:simpleType name="WcbString">
<xs:restriction base="string">
<xs:pattern value="[&#x20;-&#x7e;]*"/>
</xs:restriction>
</xs:simpleType>

// Define a text type which essentially says "if present, must have
// at least one character"
<xs:simpleType name="WcbText">
<xs:restriction base="WcbString">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>

// Project-specific type: case id
<xs:simpleType name="CaseID">
<xs:restriction base="WcbText">
// Yes, I know '[\dADF]\d{7}' is more concise, but I prefer this
<xs:pattern value="[0-9ADF][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"/>
</xs:restriction>
</xs:simpleType>

// Define the element
<xs:element name="wcb-case-number" type="CaseID" minOccurs="0"/>

I know our partner used XMLSPY to validate it because it had the 'edited by
XMLSPY' comment at the top. Before I respond to this, I need some
confirmation of a bug in XMLSPY.

Section 4.3.4.3 of the XML Schema specification
(http://www.w3.org/TR/2004/REC-xmlsch...types.html#dt-
pattern) is pretty clear to me on how patterns should be treated in a case
like this (ANDed, not ORed), but XMLSPY isn't working that way. In fact,
when you click on the wcb-case-number element in the XML file, it actually
shows the pattern it's using as:
"[&#x20;-&#x7e;]*|[0-9ADF][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"

Anyone disagree and think XMLSPY is working correctly? Basically, I can
work-around the issue by making the base type of CaseID the built-in
'string' type. I will be doing this because I want our partners who use
XMLSPY to be able to properly validate their files. However, I want to be
certain when I say 'this new schema change is necessary to account for bugs
in XMLSPY' that I'm actually correct.

TIA!

-Patrick

--
Patrick Maloney
New York State Workers' Compensation Board

(Remove REMOVE from e-mail address to reply)
Jul 20 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Hi Patrick,

You are right; it must be a bug in XMLSpy. If the patterns were at the
same derivation level, they would be OR-ed. But, since they are
different levels, they should be AND-ed. Making the base type xs:string
should solve your problem.

Hope that helps,
Priscilla
-----------------------------------------------------
Priscilla Walmsley
Author, Definitive XML Schema (Prentice Hall PTR)
http://www.datypic.com
-----------------------------------------------------

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Jul 20 '05 #2

P: n/a
Priscilla Walmsley <no****@datypic.com> wrote in news:418cceb8$0$14466
$c******@news.newsgroups.ws:
Hope that helps,
Priscilla


Yes, it does...thanks Priscilla!

--
Patrick Maloney
New York State Workers' Compensation Board

(Remove REMOVE from e-mail address to reply)
Jul 20 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.