| Resolving TypeDefinitions from <xsd:include> doesn't match TypeDefintion from element declare [message #58400] |
Tue, 01 March 2005 13:45  |
|
This is a multi-part message in MIME format.
--------------090701040406080700040809
Content-Type: multipart/alternative;
boundary="------------030606080606070609060500"
--------------030606080606070609060500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I've attached a simple plugin that illustrates the problem.
Basically, I have an included schema that defines 1 complex type. The
including schema has only an element declaration of type from the
included schema. I am unable to locate an appropriate API call to get
matching complex type defintions. This appears to be true for other
types of references too: simple types, element references, etc. My
assumption is that the element declarations type reference would have
returned the same object representing the complex type definition (as it
does when they are defined in the same file)
Note: the DO match if I add 'xmlns:contact="http://www.ibm.com/contact"
targetNamespace="http://www.ibm.com/contact"' to the included schema.
The schema validates as is. I don't have the luxury of changing of my
schemas to have the added schema attributes.
Here's the top-level schema (also included in the ZIP):
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:contact="http://www.ibm.com/contact"
xmlns:cntadv="http://www.ibm.com/contact/advanced"
targetNamespace="http://www.ibm.com/contact"
elementFormDefault="qualified">
<include schemaLocation="Contact_include.xsd"/>
<element name="Contact" type="contact:ContactType"/>
</schema>
Here's the included schema:
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<complexType name="ContactType">
<sequence>
<element name="Name" type="string"/>
<element name="Email" type="string"/>
</sequence>
<attribute name="gender" type="string"/>
</complexType>
</schema>
The test program shows that XSDComplexTypeDefinition instance from the
XSDInclude.getResolvedSchema().getContents() does NOT equal (via the
"==" operator) XSDElementDeclaration.getTypeDefinition().
This affects me as I depend on the hashCodes to be the same to ensure I
don't reconstruct more that I need.
Note about the sample code:
- Adds a menu option to context menu for *.xsd called "Parse XSD with
Include"
Thanks in advance,
Steve
--------------030606080606070609060500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I've attached a simple plugin that illustrates the problem.<br>
<br>
Basically, I have an included schema that defines 1 complex type. The
including schema has only an element declaration of type from the
included schema. I am unable to locate an appropriate API call to get
matching complex type defintions. This appears to be true for other
types of references too: simple types, element references, etc. My
assumption is that the element declarations type reference would have
returned the same object representing the complex type definition (as
it does when they are defined in the same file)<br>
<br>
Note: the DO match if I add <tt>'xmlns:contact=<a class="moz-txt-link-rfc2396E" href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
</tt><tt>targetNamespace=<a class="moz-txt-link-rfc2396E" href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>'</tt> to the
included schema. The schema validates as is. I don't have the luxury
of changing of my schemas to have the added schema attributes.<br>
<br>
Here's the top-level schema (also included in the ZIP):<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
xmlns:contact=<a class="moz-txt-link-rfc2396E" href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
xmlns:cntadv=<a class="moz-txt-link-rfc2396E" href="http://www.ibm.com/contact/advanced">"http://www.ibm.com/contact/advanced"</a>
targetNamespace=<a class="moz-txt-link-rfc2396E" href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a> </tt><br>
<tt> elementFormDefault="qualified"></tt><br>
<tt> <include schemaLocation="Contact_include.xsd"/></tt><br>
<tt> <element name="Contact" type="contact:ContactType"/></tt><br>
<tt></schema></tt><br>
</blockquote>
Here's the included schema:<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
elementFormDefault="qualified"></tt><br>
<tt> <complexType name="ContactType"></tt><br>
<tt> <sequence></tt><br>
<tt> <element name="Name" type="string"/></tt><br>
<tt> <element name="Email" type="string"/></tt><br>
<tt> </sequence></tt><br>
<tt> <attribute name="gender" type="string"/></tt><br>
<tt> </complexType></tt><br>
<tt></schema><br>
</tt></blockquote>
The test program shows that XSDComplexTypeDefinition instance from the
XSDInclude.getResolvedSchema().getContents() does NOT equal (via the
"==" operator) XSDElementDeclaration.getTypeDefinition().<br>
<br>
This affects me as I depend on the hashCodes to be the same to ensure I
don't reconstruct more that I need.<br>
<br>
Note about the sample code:<br>
- Adds a menu option to context menu for *.xsd called "Parse XSD with
Include"<br>
<br>
Thanks in advance,<br>
Steve<br>
</body>
</html>
--------------030606080606070609060500--
--------------090701040406080700040809
Content-Type: application/zip;
name="xsd.include.sample.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="xsd.include.sample.zip"
UEsDBBQACAAIAGY/YTLKfBFNpQAAADMBAAArAAAAY29tLmlibS5ldGVjaC54 c2Quc2FtcGxl
LmluY2x1ZGUvLmNsYXNzcGF0aJ2PPQvCMBRFZwX/Q8huqptDaxGpoEOVUmep yaONxpeYD9F/
b1WKLjq43Xs5HLhxej0pcgHrpMaEjtmIEkCuhcQ6odtyMZzQdDrox1xVzpnK N23pvRugtzdy
lCgS6iyn5DG+YvSd5Bo7UtuaAVfSOGBGAOPaArNwDtKC2KhQS3R/qA7CM1UF 5E17hK2KbDdf
5+VsmWfFL5sO3gTfCfcSn3Acfb6/A1BLAwQUAAgACABmP2EyeuWsDvUAAAC1 AgAAKQAAAGNv
bS5pYm0uZXRlY2gueHNkLnNhbXBsZS5pbmNsdWRlLy5wcm9qZWN0vZLNTgMh FIXXmvgOzexl
dOeCTpNq3GlMqg9AL9cpDVwIP00fX0BGM5mYuDDu7jmcw0cAvjkbvTqhD8rS urtlN90KCaxU
NK67t9fH67tuM1xdcuftESE+YACvXMzp7F5wEgYHsIapvWEYEQ7sHCQLwjiN TBHoJJH3NVby
OWqQ4sD7aSpu2zxU0c/UPiktdw6hqCbvc1WQrE47gvUjQ9DKBWRHGRlYnwdx ErWA/vsIuSH8
mAo7NN3PDd4vKL/iOonsSZB6xxC3/4vdwQGN+BNoc6Yrz7yYPLb0p1jgX3Qa FT3XxUKvoZ8K
s+ehRWeaC/HrL8y/3QdQSwMEFAAIAAgAZj9hMgOdOjbzAgAAIwYAAFkAAABj b20uaWJtLmV0
ZWNoLnhzZC5zYW1wbGUuaW5jbHVkZS9iaW4vY29tL2libS9ldGVjaC94c2Qv c2FtcGxlL2lu
Y2x1ZGUvSW5jbHVkZVBsdWdpbi5jbGFzc5VTWVPTUBT+LpSWlghS9kUFBGyD 5iIuiEVcUGeY
KY4jynuaXkogTTpJqvUX8QouwPjgow/+KMdzb1IWHWDoTHNPzvKd737n5Pef Hz8BGHjGYFhe
ldulKhehsDZ5IyjzwKzWHMFt13LqZcFXovOtU6/YbgqMYdrzK1xYjl0LBK/b vKZC/HkpCH3T
Cj+sNHNbGZJRkGG2eLlOBYZOXwRe3bfEi7pbdgTDcHHL/Gjyemg7/N2pGGUn F23XDpcYWnP5
dYbEslcWGtLIZJCApqENyTRa0MkwT0wMYmIoJgYxMSImRszEOMWk2Slox1WG wbMopJBlSFdE
2GRr5CK6julW+Fro226lkD/7Bhp60ZdBD/o1pNAuuQ4yTBznr9pBQBjNslcN S9RC2yOdhxm6
irYr3tSrJeG/N0uyfbboWaazbvq2fI+diXDTDhhYg2GyeDE0ydoWhKYfMkzl inLsXlCx+YZv
VsUnz9/mEfdlzw1FIyxI3TNHxdSn51iAE3QnNYxjQo5lmiFlRcV01Ysb0AWC 0Ktp0KP6GepH
ir8UG2bdIYi5XP7ya9ZNCM2bR2OiFT97diddGu7AyNCk7p6Gaa7AaO7cgd/D fVn8INqbCFPD
PGblGjyiTd4Wn+Ug/+tL216KWzD6Z9YU7mtbzf3U/QxZS3K3kFqgZ0Z+B8qi HaMzCSa/EXp2
0Ns2+VvoHNEPcEX/ii49232Ige8Y2kG6qDMy9ii1nVa1FyOUOkrJwwqwlxr0 UWSArEGyhsg/
gmsU6Y8gcV3l9RGBGxgjFCa3gGI3yZugtylFYSmmkNRnDnBrT1GVXTLKO07V EydQkzGqtHLI
K1T9ItTb/6LmCDV/LmpaDjoWaZJO+Ut8QdfuEVJSeblCkRhpsmfjii3ytNI5 eIi5fTwszvxC
x4y+j4UdJPTdVX2X8lKkTN+Rplk1rnnyLpD3MfEqKOSxCIc8BTpT6MYiac4U 7ycUbSGbtiru
y5UeQJv+DUP/Ul1WgFqUEF+YkVAy6+lfUEsDBBQACAAIAGY/YTIT+I/TNwoA AMIVAABtAAAA
Y29tLmlibS5ldGVjaC54c2Quc2FtcGxlLmluY2x1ZGUvYmluL2NvbS9pYm0v ZXRlY2gveHNk
L3NhbXBsZS9pbmNsdWRlL3BvcHVwL2FjdGlvbnMvUGFyc2VYU0R3aXRoSW5j bHVkZS5jbGFz
c6VXeXwcVR3/vjTJbHYn0C5Q2Qp0aVOaljQDpUVMSwtN0rKSBOyGIwWLk91J dtrdnWVmtoci
ioJKFUUBlYogqARvKJA2VKEoUkWxqOCNeIsn3rfg983b3SSbpYkf/8hm3nu/ +31/x3vs+Qce
BNAuGgTWpZycYQ/mDMu3Uhljh5c2PDNXyFqGnU9li2nLKDiFYsEwU77t5D3j fNP1rIuTXdtt
P5NQFBqEwOwt5jbTyJr5YeO8wS1WytcwS6DFcYcNK5W1C55lFG0joc7ODoR1 WVlr2PTJTzs0
al5vZy2BBT0TmVKOaxmu5TlFN2V5RkLSrCJ5Kmt6XsspAnN6xjV3yk2eNiV3 5v2M5dupCuWp
la/lAo2r7bztrxGY1brkQoH6Tidt6TgCR4ZRjzkCR/bYeauvmBu03H5zUBoV 7XFSZvZC07Xl
urRZ72dsT6Cr5/+PIY1u9qwgMNssnvsU2zopEFuGzJRVEmEkVARX9VTH9yLH 3Tpo5VMZKWOV
dK5RsVTHtaY4gbBvusOWryyYP414xs8tUvKiGVgqTTl+IpW33Te222kq84xk xspmNcwPIy7D
P3f8RpO+a+eH1xWHhixXwwKBowpZ0x9y3FxHBRVGCC0Cx7T2VLNRqbzVk8JY iMU6NISaUIcl
AvHpEKbhZMZCBsJ1JGAFFrcuOSwuS4SrdCxDewRtMAQWzoBBg0QmNfWZOULq aKqZ4oaO07Ai
guVYKa+zULDyaYG2Wv5O2VKRo4SX4QwZhpcLCMaLVzd33LuNFmMa4M7PECc1 PS3mfTtn0WzS
UNyZWCOdXCtwwuFpNZwtEPIdZY6OTunJOnRJY7oETpvIbeWG+D0xTobNNDI2 llZJy09wrWFD
GOdIoMyv5mYi5gi6om9njQs2JjS8gsUg5VqsMlwKrKwZtGmk0N0e9IZxLvoE lk5j8ARbNZwv
EGGYy3sCva3TKts01Z4XUUG7NiIZwSvRT3zOkEmDLHhZxySEoqVoBLp7zUKQ LxdjIIKLsEmZ
3unkfSvvezLJDx+o7h7bk/C/FK+S/JsFTpyWXMOrWUOoRqZvYiJ6VZ+guEGk IjBBa2MTxcka
ywqaTGWsnKlhKIJhqTJk+5Zr+o5LfJczKVCXKO1Too0tUuJW+j/1XEOO4clb O/zqXKxY5KAQ
QR6X62hCWBYUBmcebWsv2dZO29ppW6myh1BkQ6nqURq2M+tZxlTWL5oml1Vf 07ETrwljB17L
rBs/7HOC4y5raL1TzKe7XVe68TqWynGa/ozrbJdNS8PrVWHrtTzPHGbXuwor wngD3hjGlVjM
M9tL5D3fzEu4TqqppQAs2aTjGrxZ2vEW5Xj1pVTGgmvZnUvwz26z0uqy2Aaq kDTpLunl2/D2
CHbhOh26CvA7BVprBLjTkT12R//OgkXnZUdnownhXYq6WnxNag038B4yptcX 3DjHAXp3E94j
L/i9OpqV/pt5QzX0d2etHHOji9smwRMof78irVY+lVTDB1TdlwZNza4S32Rr GZvb8MEIbsXt
KrKTj3V8SJ1+WKCz3/L8+JDJXpZui6ecYjYdzzt+vFwP4qXJJM1WyE32CHZ1 yyNlEKW4T8kh
3MlWWYpbXOqKpyvKvHjO9FOZjngId7EryY5sMoJrWmu5UTP2NboVHfwYPh5m yD8h0D5Jc9cE
zWknv9gv6w83bXQcX9rxKQE93FRCX1ru3M0cp/p4aS+eDKayEPZU1Us1saRt M+sMe0YpNbqC
pYb7mL4Oe24ir5wMhqn1k/2cMsysmupb7fFkFHvDuB/7yulqOxySu3ekrIJC yQPUXiC1n/TN
1NZ+l4bq+IycVPfjs7yeqiLR5/iqCoxLeEigwZM2VQ90U41mAR0iYlRRik41 mD3BHe9vnEFm
2qpILYW7lUY48yYndfKCS9hhA545wBi6Mswr7GEvKDMSMwIvPUwdIpik3vEG eHStdsKa4Qxu
mRysUqEUOKKsvVz5Zpc3xqVGylvnSTGapQoF8VnLtKllRD6F/LJvC2dQQmhw zhvmFCjLe08N
yJFitkczgrG9M0OHLDbfc//Xx4ii2GZb2y2X026yLDF4CCx7cUoirZjyiy6D VmbR8APeJGG6
3nY9vxQDHT9EIYxn8CNOeBV7BU6amRUMA5kEjMOQ1zCFfKI1hF8Qy2waGflu DLpGQscv8Sv5
evw1UTV5lJkyiP9Wzr6/E6hbwhL1e2JHVvLg2SUTzysEKf5HOSffiD9R4cIQ /iK/Of3XtZHl
7/SYxApUOv4p2+WN+JdqCWpXvlZVS/iPlDOM54k01gc/aQ0H0ROQbf9cwZd7 OBkkmnp8H1vj
bdoufcGJrMr1YKnnb718SwGzQ3IE4l4ECFb6pFXz+AoN/OL7mr+zuTqN/4Xc XboX0Xv4UYej
+CsLP6ioHgtwNL90RYRjMJf/BV6CY0sC1vJvltwbZ24MiFsDxrg6LDHKrxjm Bee8HRxHDk4h
OEEJm7WT1Efw6Kn9iA/sxYm9+7FwILpoL1qX3oelYzhFYAynC5bqjuhq/qjd s+Rud7A7ivV9
+3EOeRMd9bH6ZftwXv0YLpiFjoZYgxjDJdTX0Sg6tFjDGC4jYMZg1eEAhjtC sdAYMlISsdjR
NIKnY01j4PTaEd4Df+Agjrsoum0frhi4F/4IjtyPKzddNoo37cXVD8XCo3jr zcjEwgewawzv
IE8kFpkgTR/BmpiupDXvwfVK2ruVtOurpTUH0ppjzQdwY4c2gn7J+j6B3S88 OIINe7Bbsd+i
2HfXNma+NOZWZccd0gT58REBKbNRehYInB9rfBShmHYQ4ehIR3gEfXKjJdYY 0+7E8UHwPyqD
H2scxSdVeCVVa3Dy6Ykn0XvkdcS0CXRt0Xtj4X0YG0Got20UD95DNN2E3bid RvwEz+I5HBAL
xGLRzjXEIXGIfVQB6A6CBzAI7FOJv+U4g/9XYwW6sRIbcDqfWSuR5O4l6MBm rOIT4kx4WMMB
ei2uxlm4Dmezka/Dw3zjHkIXvk7O72G9mIUNgu9V0cz37jym3Dr0iAR6xUY+ JzfzBZ1BUrh8
wu3EBeIavs5uw8XiLgyIh/j/EVxKCzeLJ/hQepJvIQnux+SveKoMbn4pcIfE Qer+HL1ZLW7A
5/EIYd0tduELeJQxSIorcBBfZDZtFpfjS5TSCFPk8WV+aXzCXIqv4HH6fpXo w1dpfxP9+Rqe
4F+YUgfozeNM5UN8BH+Dvzo9W44nedpMX47BU/gmIvRIx7fwbehiG3V/hxaE xS2Vr0fIr76e
oD3fpQSZht/H06Wc3sV1A/+3tD2MZ4iltgN4pm/ZKH4sc+phtN0MfWms/gDa 7sfS8bSfRz+A
DH2wqX0LotjKvSwrrBNEa4WSWSkFLZVS0EI8/JRSdNaVn+HntDOKOYHHssxx Di3ZdS1PZF1K
BPh7lvg7eRS/GcVz0T8QdCeP4c+qNPxVrf6mVv9Qq3/LbHxBgCVhVNQpkN5d MT5KVYBLYz2C
zSdg3MDouUphxegEw/qYrJlC1rU6Uf9fUEsDBBQACAAIAGY/YTLWEoGIRAAA AG8AAAAxAAAA
Y29tLmlibS5ldGVjaC54c2Quc2FtcGxlLmluY2x1ZGUvYnVpbGQucHJvcGVy dGllcyvOLy1K
TtXLzEvOKU1J1ctKLFKwVSguStbn5covLSkoLUGTSsrMA0oBSZh4MVCwIKc0 HShSkZujE8PL
pYAKkPTzcgEAUEsDBBQACAAIAGY/YTLDuuwqtwEAAOUEAAArAAAAY29tLmli bS5ldGVjaC54
c2Quc2FtcGxlLmluY2x1ZGUvcGx1Z2luLnhtbJVTyW7bMBC9B8g/CDwGMFUj lxykGF1gwIcA
BtICvVLU1J6AW7kk6t+XImlLrpFW5Umc5b2nN8NmM0hRvYJ1qFVL1vQDqUBx 3aM6tOTb1+3q
gWweb2+aDXCBxsFUex9rU8qIcEB1e1NVFfYt4VpS7CQFD/xIB9dTx6QRQFFx EXogqVIxCS3Z
5VC1jxArVDk1VxM5UsxY/Yo92FXp+/SU41ww5/7NSQvRPkklUXXqbmxQHiU8 ptsYENhZZn8V
eafuF2bJuWYsg8Fo60vVHakngLog5EhTTwyFEX4GtOCmDpQJK7vYEm0PtHhN A86h/1LItQVa
qBa2RJMWVoL8Eb9HhkH+nyBwOlgO7tQU7Zh+P0dg8KDGcc/sNRqV/9MJarQJ 5glUcNMsGt29
APeftfIWu+AvceIp+bwl7wukuy2KspnnM043hj3YOOPk12V+ybJHnkna+nKJ GL/WG49gHYiW
7JmNr+3785fqDf2x2s0fz/wsfQHJPpo5HU3oEXzEfhdaRrM7ZvfMH1vC+h5T 73UdKNYJcFsd
jVpfpxf5pODtY9J26VGdBc/e1/XET7t1XqW0XE2d9zJefgNQSwMEFAAIAAgA Zj9hMndD55pI
AgAARQYAAFgAAABjb20uaWJtLmV0ZWNoLnhzZC5zYW1wbGUuaW5jbHVkZS9z cmMvY29tL2li
bS9ldGVjaC94c2Qvc2FtcGxlL2luY2x1ZGUvSW5jbHVkZVBsdWdpbi5qYXZh nVRNb9swDD0n
QP4D10vtYFPuC4phX4ceBgzd9gMUmUm0yJIgUWmKof99lGW3cZtmxYAgcUTy 8fHp0V6qndwg
KNcKvWoFEqqtOMRGRNl6g0JbZVKDy9l0NtWtd4HAhY1AZbSPKJIW3qSNtmK+ HCW4uNFiHWSL
ty7sxKdkG4OfnSU80GPmb7mXIpE2XflsupjPZ1OYw88tQiu1hQIOysgYgRys EFLEBviMOKfB
uCPnRS5azKY+rYxWffZ1Yf69IHBbtE2Ej6tIQSr6dd0H/symk8UiN4xbGTro SNIqZNCJD3ov
iUMkiYHHkIXbsqu/wehSUAirbtDj2iFUJIAw+purM0Cee9IPrhwzCEmRC6I7 XWS0MtqIQVV3
7CcxeQxVnbEmvWBXLI+O3QmFu5I2GbfmnDE1sUEqT9XFv/wgRkQGnHhRSNyD kqS2UH3TMWq7
GeJfDwo9aWfhUL/EySZjCgh/3WdTHKujI7RIW8fXFLmJMXxhybtyGe94cL7a LDv3eCrd3ukm
X2SgauTGrHf+rVmy4G4jPLJ8VFeUwiF1+Vput1ssTh34cSiyYz02L/Bz/v/o cd0ZdjdIKdjY
UTnh8xGRk2Znb3zBtUyGBteFDvJoC861pMA2gHVw7YMa2l7Gh23o9+ZtKXUB Lnd4dwl6DdYR
rB1HX+L5o2AzwcFm5aTqAwzUM36yiavBcqNJxfGk4gi1X4362VJ1MlQ92pvi 4Bo+DK8ChugJ
dUzeZ0Kv3BKsx00eKs+rfV7dIwWfCHJi2NFVP391MQn+/AVQSwMEFAAIAAgA Zj9hMiq9DlLs
BAAALRAAAGwAAABjb20uaWJtLmV0ZWNoLnhzZC5zYW1wbGUuaW5jbHVkZS9z cmMvY29tL2li
bS9ldGVjaC94c2Qvc2FtcGxlL2luY2x1ZGUvcG9wdXAvYWN0aW9ucy9QYXJz ZVhTRHdpdGhJ
bmNsdWRlLmphdmGVV99v2zYQfvdfcXOBTko9enutEWBF3AIGtmaIM2wPeZGl s61EEgWSilO0
/t93R4kSJctOFiCJLH738fjdD57LKH6KdgixzEW6yQUajPfiRSdCR3mZoUiL OKsSFKUsq1JE
sUlloReTSZqXUhl4jJ4jkUqxuv38EmPJq4veWmXSTKwMqshI1dlJtRMYZ2mp UcRSoVCoZaVi
1GL1Jc1wMQbEfEvgPJdFTfv33eosDnus4q55+L/4NZq3mhAq8+1W9HnU9nEb EbyWUqw+xT3R
ToFJGmVyp8WfqDWFamk/XsA/p3hARTquMcPXyB14bVQVm0phctlKH4w4pMkO DdnsMRs/YZW6
cy2JbReZcd0Zdrt5pO3eCP5HqqcNFvH+r0iNx4Uz99/18kZy8r7cfytxidu0 SM8eqDH4nGGO
hVnS64hS9RX0qi6KS5B1vMc8uoQYOjcpq02WxkAeaA10Qo2EOqRm32wHnGHW TQ2jusH3yQSg
VJKK2GACtpKAtqsritbmV1f0F67ghqrYhlwq2NJvTfSbsKtzZqmdGXEjCGkf goGuSlRBuKAP
xx757xpx3MN3Gu2bZ+QIBk2SzKAf2XDoxbNMExg1hWiUAUykKEctmfV2zMGB a6oqHOu4Ax6g
2dYpYdS35gnAVgVo+/caCjzUb1gnhzAqLXawpaB8jXIk1LTMIkNhyD/OXTuZ T+GDC53goyjJ
cgYhf2CzIGzo+OcDTM8Y3CFRW9HMnoyNrHf33PFaFijvuXZ+0NDqcPtmrQ0Z eOaec+yNQwfU
s0WskASnp8BpEM5Iwwo7p9qumskoCYoqy7q1c/UNSkrTvGLvK+5Or5g011sy NOvs6kIGbf/d
0Q6ECdr3YecpnZKqynB51lEKfm3FchegddGhiKhjHZinjUGn92HPxRz4BGIf 6a/4QkkRtukH
UNcdyM0jR8SHFxa7aJHp1p6kqWthG49I9YpaQ1RQrIiix+zr4YRrPpImHlXI u4cu7tmzg/mb
e6I4Lk+YPv2r4ngCDcnGRfKEcga3VrAT86FonnCjKXUqo7fBiQ8wkoFnqUPf 18WAZ0NF9dR/
eZyMPR8BM43uDKcX3xvz4NSQeO2r5ginAJsWiz7NoB5Nq0JDxqFnTD8E/Uq/ INiApVvy+Zw2
x0GHzvXOgVgt7gxwfd3b/McPcK8HgezaM9Fwj79HbWAbUZImM5q3qyyBQnYt t7UHbhO4RUWX
GWqezPlgVpmpc6eNoN38p75P79/39Tl1zYtl41wjHzACklYlDXlk4v1H4MuF L6jIBB53q2GT
U5dplx5tIoufjSN/KJh++mC4EdJevSQe3dfCiwfT9Juk5+DwtItheHuTtJAl FquituXEsFf3
DKaUVOAmr7X9MjSd8bncRXSEmN2HwPvuA9hpO5/D/e3yFj5VRv6yw4J7FkW3 NtpkMn5ywRQl
pZtZG/oudq9oKne5eXzb4KLdxH6zj4odJt5Y1Q7z50aqcctuqmoJOqw7Iadf +5JSrG4Wcgsj
3yU6VUYWmZqreNROd19HaoLe9UarXNpfUqVN02+6wmYHGea5ZidiP/2bgYm3 b9a8FnXsR6FR
zo1vdbKdnSxMv9YU0skKmAacqM0aX037G2lHakroEPw17lh2iOX5SJc2LRj1 riuPHrieCRkx
Ax/SH7g8A3cld89/yLgugTAUdAeYNe46RY+T439QSwMEFAAAAAgA72lcMnZi qg5aAQAApgIA
ABMAJABDb250YWN0X2luY2x1ZGUueHNkCgAgAAAAAAABABgAYM3ge8EdxQGQ CXrfXh7FAZAJ
et9eHsUBdZJPb+IwEMXvlfgOUx+REvPnslolQRUtp7YXWGmvJhmIJcc29qSh 3742CSWqyiGW
ZvT8m/cmzlbnRsEHOi+Nztk8nTFAXZpK6mPO/u02yR+2KiYPmS9rbAQEtfY5 q4nsX867rku7
ZWrckS9mszn///a6vegCRGGDmjbGNc94EK2inJ1aoeRBYsUCcfIAkD0mCezQ EwgoTWMVnnef
FqGTVIeWl7EFHk9t8IQgdBU+EERO7lvCNDIAplPY1qZVVWBoT64tI2+thPew NppESTeqJ3Ro
KNajid+gOOI2z1oV3KYAuxphcc3kL6r5zUcgKwV7hOU3x3Qaq6erwIPRQIHR m7oYieWYEBNb
64x1UtDIUO9h5HtInSTFZYXjvWnRYM5GmVnRi7NrpqEOnSHMcOc9nAwiPmdh heHvM35P+9II
qe6IM/5jUnbL2N8+oq7Q/Xo946Mw8dHx/tUVX1BLAwQUAAAACACNOGEy9Dox YxkBAADoAQAA
HAAkAENvbnRhY3RfdG9wbGV2ZWxfaW5jbHVkZS54c2QKACAAAAAAAAEAGADg 3i7PVh7FAZAJ
et9eHsUBkAl6314exQF9kD9PwzAQxfdK/Q6Hx0qJU1hQlbQDqFNhoUhsyDiX xJL/BNtp2m/P
NTGVWPBk+3733rsrd2ej4YQ+KGcrts4LBmilq5VtK/Z+3GePbLddLsogOzQC iLahYl2M/Ybz
cRzz8SF3vuX3RbHmHy+Ht4ljM7iRzkYh458G9WVy6QxPtRtKr/r0H8mpLqzE mkEUvsX4KgyG
Xkj8X3+5ADqo0aCNe+fNMzZi0JTqexBaNYoUacQrVt5lGRwxRIidiCCAhHqN 5+OlR1AWhHWx
Q09XqYcaaziHGhqlETwGp08YoPeuR68vs+tqleyzbDsZpE6Y93lwUsRp809z 2s9Uz0mY8d9U
KTtYGviG0hYoVcXSnJv0fY2aOks+u9DjB1BLAQIUABQACAAIAGY/YTLKfBFN pQAAADMBAAAr
AAAAAAAAAAAAAAAAAAAAAABjb20uaWJtLmV0ZWNoLnhzZC5zYW1wbGUuaW5j bHVkZS8uY2xh
c3NwYXRoUEsBAhQAFAAIAAgAZj9hMnrlrA71AAAAtQIAACkAAAAAAAAAAAAA AAAA7gAAAGNv
bS5pYm0uZXRlY2gueHNkLnNhbXBsZS5pbmNsdWRlLy5wcm9qZWN0UEsBAhQA FAAIAAgAZj9h
MgOdOjbzAgAAIwYAAFkAAAAAAAAAAAAAAAAAKgIAAGNvbS5pYm0uZXRlY2gu eHNkLnNhbXBs
ZS5pbmNsdWRlL2Jpbi9jb20vaWJtL2V0ZWNoL3hzZC9zYW1wbGUvaW5jbHVk ZS9JbmNsdWRl
UGx1Z2luLmNsYXNzUEsBAhQAFAAIAAgAZj9hMhP4j9M3CgAAwhUAAG0AAAAA AAAAAAAAAAAA
lAUAAGNvbS5pYm0uZXRlY2gueHNkLnNhbXBsZS5pbmNsdWRlL2Jpbi9jb20v aWJtL2V0ZWNo
L3hzZC9zYW1wbGUvaW5jbHVkZS9wb3B1cC9hY3Rpb25zL1BhcnNlWFNEd2l0 aEluY2x1ZGUu
Y2xhc3NQSwECFAAUAAgACABmP2Ey1hKBiEQAAABvAAAAMQAAAAAAAAAAAAAA AABWEAAAY29t
LmlibS5ldGVjaC54c2Quc2FtcGxlLmluY2x1ZGUvYnVpbGQucHJvcGVydGll c1BLAQIUABQA
CAAIAGY/YTLDuuwqtwEAAOUEAAArAAAAAAAAAAAAAAAAAOkQAABjb20uaWJt LmV0ZWNoLnhz
ZC5zYW1wbGUuaW5jbHVkZS9wbHVnaW4ueG1sUEsBAhQAFAAIAAgAZj9hMndD 55pIAgAARQYA
AFgAAAAAAAAAAAAAAAAA6RIAAGNvbS5pYm0uZXRlY2gueHNkLnNhbXBsZS5p bmNsdWRlL3Ny
Yy9jb20vaWJtL2V0ZWNoL3hzZC9zYW1wbGUvaW5jbHVkZS9JbmNsdWRlUGx1 Z2luLmphdmFQ
SwECFAAUAAgACABmP2EyKr0OUuwEAAAtEAAAbAAAAAAAAAAAAAAAAACnFQAA Y29tLmlibS5l
dGVjaC54c2Quc2FtcGxlLmluY2x1ZGUvc3JjL2NvbS9pYm0vZXRlY2gveHNk L3NhbXBsZS9p
bmNsdWRlL3BvcHVwL2FjdGlvbnMvUGFyc2VYU0R3aXRoSW5jbHVkZS5qYXZh UEsBAhkAFAAA
AAgA72lcMnZiqg5aAQAApgIAABMAAAAAAAAAAAAgAAAAHRsAAENvbnRhY3Rf aW5jbHVkZS54
c2RQSwECGQAUAAAACACNOGEy9DoxYxkBAADoAQAAHAAAAAAAAAAAACAAAADM HAAAQ29udGFj
dF90b3BsZXZlbF9pbmNsdWRlLnhzZFBLBQYAAAAACgAKADUEAABDHgAAAAA=
--------------090701040406080700040809--
|
|
|
| Re: Resolving TypeDefinitions from <xsd:include> doesn't match TypeDefintion from element decl [message #58424 is a reply to message #58400] |
Tue, 01 March 2005 15:43  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------030606070207060308090001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Steve,
The resolved schema is the original schema without a changed namespace.
You need call getIncorporatedSchema to access the cloned version that
has the namespace retargeted.
Steve Speicher wrote:
> I've attached a simple plugin that illustrates the problem.
>
> Basically, I have an included schema that defines 1 complex type. The
> including schema has only an element declaration of type from the
> included schema. I am unable to locate an appropriate API call to get
> matching complex type defintions. This appears to be true for other
> types of references too: simple types, element references, etc. My
> assumption is that the element declarations type reference would have
> returned the same object representing the complex type definition (as
> it does when they are defined in the same file)
>
> Note: the DO match if I add
> 'xmlns:contact="http://www.ibm.com/contact"
> targetNamespace="http://www.ibm.com/contact"' to the included schema.
> The schema validates as is. I don't have the luxury of changing of my
> schemas to have the added schema attributes.
>
> Here's the top-level schema (also included in the ZIP):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> xmlns:contact="http://www.ibm.com/contact"
> xmlns:cntadv="http://www.ibm.com/contact/advanced"
> targetNamespace="http://www.ibm.com/contact"
> elementFormDefault="qualified">
> <include schemaLocation="Contact_include.xsd"/>
> <element name="Contact" type="contact:ContactType"/>
> </schema>
>
> Here's the included schema:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified">
> <complexType name="ContactType">
> <sequence>
> <element name="Name" type="string"/>
> <element name="Email" type="string"/>
> </sequence>
> <attribute name="gender" type="string"/>
> </complexType>
> </schema>
>
> The test program shows that XSDComplexTypeDefinition instance from the
> XSDInclude.getResolvedSchema().getContents() does NOT equal (via the
> "==" operator) XSDElementDeclaration.getTypeDefinition().
>
> This affects me as I depend on the hashCodes to be the same to ensure
> I don't reconstruct more that I need.
>
> Note about the sample code:
> - Adds a menu option to context menu for *.xsd called "Parse XSD
> with Include"
>
> Thanks in advance,
> Steve
--------------030606070207060308090001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Steve,<br>
<br>
The resolved schema is the original schema without a changed
namespace. You need call getIncorporatedSchema to access the cloned
version that has the namespace retargeted.<br>
<br>
<br>
Steve Speicher wrote:
<blockquote cite="midd01rld$ete$1@www.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
I've attached a simple plugin that illustrates the problem.<br>
<br>
Basically, I have an included schema that defines 1 complex type. The
including schema has only an element declaration of type from the
included schema. I am unable to locate an appropriate API call to get
matching complex type defintions. This appears to be true for other
types of references too: simple types, element references, etc. My
assumption is that the element declarations type reference would have
returned the same object representing the complex type definition (as
it does when they are defined in the same file)<br>
<br>
Note: the DO match if I add <tt>'xmlns:contact=<a
class="moz-txt-link-rfc2396E" href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
</tt><tt>targetNamespace=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>'</tt>
to the
included schema. The schema validates as is. I don't have the luxury
of changing of my schemas to have the added schema attributes.<br>
<br>
Here's the top-level schema (also included in the ZIP):<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E"
href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
xmlns:contact=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
xmlns:cntadv=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact/advanced">"http://www.ibm.com/contact/advanced"</a>
targetNamespace=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a> </tt><br>
<tt> elementFormDefault="qualified"></tt><br>
<tt> <include schemaLocation="Contact_include.xsd"/></tt><br>
<tt> <element name="Contact" type="contact:ContactType"/></tt><br>
<tt></schema></tt><br>
</blockquote>
Here's the included schema:<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E"
href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
elementFormDefault="qualified"></tt><br>
<tt> <complexType name="ContactType"></tt><br>
<tt> <sequence></tt><br>
<tt> <element name="Name" type="string"/></tt><br>
<tt> <element name="Email" type="string"/></tt><br>
<tt> </sequence></tt><br>
<tt> <attribute name="gender" type="string"/></tt><br>
<tt> </complexType></tt><br>
<tt></schema><br>
</tt></blockquote>
The test program shows that XSDComplexTypeDefinition instance from the
XSDInclude.getResolvedSchema().getContents() does NOT equal (via the
"==" operator) XSDElementDeclaration.getTypeDefinition().<br>
<br>
This affects me as I depend on the hashCodes to be the same to ensure I
don't reconstruct more that I need.<br>
<br>
Note about the sample code:<br>
- Adds a menu option to context menu for *.xsd called "Parse XSD with
Include"<br>
<br>
Thanks in advance,<br>
Steve<br>
</blockquote>
<br>
</body>
</html>
--------------030606070207060308090001--
|
|
|
| Re: Resolving TypeDefinitions from <xsd:include> doesn't match TypeDefintion from element decl [message #58442 is a reply to message #58424] |
Wed, 02 March 2005 13:40 |
|
This is a multi-part message in MIME format.
--------------060307030206010309080709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
Thanks. That did the trick.
Ed Merks wrote:
> Steve,
>
> The resolved schema is the original schema without a changed
> namespace. You need call getIncorporatedSchema to access the cloned
> version that has the namespace retargeted.
>
>
> Steve Speicher wrote:
>
>> I've attached a simple plugin that illustrates the problem.
>>
>> Basically, I have an included schema that defines 1 complex type.
>> The including schema has only an element declaration of type from the
>> included schema. I am unable to locate an appropriate API call to
>> get matching complex type defintions. This appears to be true for
>> other types of references too: simple types, element references,
>> etc. My assumption is that the element declarations type reference
>> would have returned the same object representing the complex type
>> definition (as it does when they are defined in the same file)
>>
>> Note: the DO match if I add
>> 'xmlns:contact="http://www.ibm.com/contact"
>> targetNamespace="http://www.ibm.com/contact"' to the included
>> schema. The schema validates as is. I don't have the luxury of
>> changing of my schemas to have the added schema attributes.
>>
>> Here's the top-level schema (also included in the ZIP):
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <schema xmlns="http://www.w3.org/2001/XMLSchema"
>> xmlns:contact="http://www.ibm.com/contact"
>> xmlns:cntadv="http://www.ibm.com/contact/advanced"
>> targetNamespace="http://www.ibm.com/contact"
>> elementFormDefault="qualified">
>> <include schemaLocation="Contact_include.xsd"/>
>> <element name="Contact" type="contact:ContactType"/>
>> </schema>
>>
>> Here's the included schema:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <schema xmlns="http://www.w3.org/2001/XMLSchema"
>> elementFormDefault="qualified">
>> <complexType name="ContactType">
>> <sequence>
>> <element name="Name" type="string"/>
>> <element name="Email" type="string"/>
>> </sequence>
>> <attribute name="gender" type="string"/>
>> </complexType>
>> </schema>
>>
>> The test program shows that XSDComplexTypeDefinition instance from
>> the XSDInclude.getResolvedSchema().getContents() does NOT equal (via
>> the "==" operator) XSDElementDeclaration.getTypeDefinition().
>>
>> This affects me as I depend on the hashCodes to be the same to ensure
>> I don't reconstruct more that I need.
>>
>> Note about the sample code:
>> - Adds a menu option to context menu for *.xsd called "Parse XSD
>> with Include"
>>
>> Thanks in advance,
>> Steve
>
>
--------------060307030206010309080709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
Thanks. That did the trick.<br>
<br>
Ed Merks wrote:
<blockquote cite="midd022j9$lgb$1@www.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Steve,<br>
<br>
The resolved schema is the original schema without a changed
namespace. You need call getIncorporatedSchema to access the cloned
version that has the namespace retargeted.<br>
<br>
<br>
Steve Speicher wrote:
<blockquote cite="midd01rld$ete$1@www.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
I've attached a simple plugin that illustrates the problem.<br>
<br>
Basically, I have an included schema that defines 1 complex type. The
including schema has only an element declaration of type from the
included schema. I am unable to locate an appropriate API call to get
matching complex type defintions. This appears to be true for other
types of references too: simple types, element references, etc. My
assumption is that the element declarations type reference would have
returned the same object representing the complex type definition (as
it does when they are defined in the same file)<br>
<br>
Note: the DO match if I add <tt>'xmlns:contact=<a
class="moz-txt-link-rfc2396E" href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
</tt><tt>targetNamespace=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>'</tt>
to the
included schema. The schema validates as is. I don't have the luxury
of changing of my schemas to have the added schema attributes.<br>
<br>
Here's the top-level schema (also included in the ZIP):<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E"
href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
xmlns:contact=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
xmlns:cntadv=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact/advanced">"http://www.ibm.com/contact/advanced"</a>
targetNamespace=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a> </tt><br>
<tt> elementFormDefault="qualified"></tt><br>
<tt> <include schemaLocation="Contact_include.xsd"/></tt><br>
<tt> <element name="Contact" type="contact:ContactType"/></tt><br>
<tt></schema></tt><br>
</blockquote>
Here's the included schema:<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E"
href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
elementFormDefault="qualified"></tt><br>
<tt> <complexType name="ContactType"></tt><br>
<tt> <sequence></tt><br>
<tt> <element name="Name" type="string"/></tt><br>
<tt> <element name="Email" type="string"/></tt><br>
<tt> </sequence></tt><br>
<tt> <attribute name="gender" type="string"/></tt><br>
<tt> </complexType></tt><br>
<tt></schema><br>
</tt></blockquote>
The test program shows that XSDComplexTypeDefinition instance from the
XSDInclude.getResolvedSchema().getContents() does NOT equal (via the
"==" operator) XSDElementDeclaration.getTypeDefinition().<br>
<br>
This affects me as I depend on the hashCodes to be the same to ensure I
don't reconstruct more that I need.<br>
<br>
Note about the sample code:<br>
- Adds a menu option to context menu for *.xsd called "Parse XSD with
Include"<br>
<br>
Thanks in advance,<br>
Steve<br>
</blockquote>
<br>
</blockquote>
</body>
</html>
--------------060307030206010309080709--
|
|
|
| Re: Resolving TypeDefinitions from <xsd:include> doesn't match TypeDefintion from element decl [message #58455 is a reply to message #58400] |
Mon, 07 March 2005 16:34 |
|
Hi,
I have a related issue that I can't seem to overcome. Basically I have
a root schema that includes 2 other schemas. One of the included
schemas happens to include the other included schema from the root schema.
Take for example I have root.xsd that looks like:
<schema ...>
<include schemaLocation="include1.xsd"/>
<include schemaLocation="include2.xsd"/>
..
</schema>
Where include1.xsd looks something like:
<schema ...>
<include schemaLocation="include2.xsd"/>
...
</schema>
It appears that the API gives me 2 different instances of XSDInclude for
the 2 different include2.xsd's. Though, the simple type definition I
have in in include2.xsd both have the same instance of
XSDSimpleTypeDefinition.
Is there a reason why I'm getting the 2 different instances of
XSDInclude? I can't seem to locate an API call that would give me just 1.
Thanks in advance for any help.
Steve
|
|
|
| Re: Resolving TypeDefinitions from <xsd:include> doesn't match TypeDefintion from element decl [message #58466 is a reply to message #58455] |
Tue, 08 March 2005 13:23 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Steve,
I'm not sure what the problem is. Clearly your example really does have
two different includes of the same schema so I would expect there to be
two XSDInclude instances that refer to the same XSDSchema instance.
Perhaps you simply need to collect all the unique XSDSchema instances?
Or perhaps you simply want to look at features like
XSDSchema.getTypeDefinitions which collects all the types from all the
schemas?
Steve Speicher wrote:
> Hi,
>
> I have a related issue that I can't seem to overcome. Basically I
> have a root schema that includes 2 other schemas. One of the included
> schemas happens to include the other included schema from the root
> schema.
>
> Take for example I have root.xsd that looks like:
>
> <schema ...>
> <include schemaLocation="include1.xsd"/>
> <include schemaLocation="include2.xsd"/>
> ..
> </schema>
>
> Where include1.xsd looks something like:
> <schema ...>
> <include schemaLocation="include2.xsd"/>
> ...
> </schema>
>
> It appears that the API gives me 2 different instances of XSDInclude
> for the 2 different include2.xsd's. Though, the simple type
> definition I have in in include2.xsd both have the same instance of
> XSDSimpleTypeDefinition.
>
> Is there a reason why I'm getting the 2 different instances of
> XSDInclude? I can't seem to locate an API call that would give me
> just 1.
>
> Thanks in advance for any help.
>
> Steve
|
|
|
| Re: Resolving TypeDefinitions from <xsd:include> doesn't match TypeDefintion from element decl [message #594374 is a reply to message #58400] |
Tue, 01 March 2005 15:43 |
 Ed Merks
Messages: 33184
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030606070207060308090001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Steve,
The resolved schema is the original schema without a changed namespace.
You need call getIncorporatedSchema to access the cloned version that
has the namespace retargeted.
Steve Speicher wrote:
> I've attached a simple plugin that illustrates the problem.
>
> Basically, I have an included schema that defines 1 complex type. The
> including schema has only an element declaration of type from the
> included schema. I am unable to locate an appropriate API call to get
> matching complex type defintions. This appears to be true for other
> types of references too: simple types, element references, etc. My
> assumption is that the element declarations type reference would have
> returned the same object representing the complex type definition (as
> it does when they are defined in the same file)
>
> Note: the DO match if I add
> 'xmlns:contact="http://www.ibm.com/contact"
> targetNamespace="http://www.ibm.com/contact"' to the included schema.
> The schema validates as is. I don't have the luxury of changing of my
> schemas to have the added schema attributes.
>
> Here's the top-level schema (also included in the ZIP):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> xmlns:contact="http://www.ibm.com/contact"
> xmlns:cntadv="http://www.ibm.com/contact/advanced"
> targetNamespace="http://www.ibm.com/contact"
> elementFormDefault="qualified">
> <include schemaLocation="Contact_include.xsd"/>
> <element name="Contact" type="contact:ContactType"/>
> </schema>
>
> Here's the included schema:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <schema xmlns="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified">
> <complexType name="ContactType">
> <sequence>
> <element name="Name" type="string"/>
> <element name="Email" type="string"/>
> </sequence>
> <attribute name="gender" type="string"/>
> </complexType>
> </schema>
>
> The test program shows that XSDComplexTypeDefinition instance from the
> XSDInclude.getResolvedSchema().getContents() does NOT equal (via the
> "==" operator) XSDElementDeclaration.getTypeDefinition().
>
> This affects me as I depend on the hashCodes to be the same to ensure
> I don't reconstruct more that I need.
>
> Note about the sample code:
> - Adds a menu option to context menu for *.xsd called "Parse XSD
> with Include"
>
> Thanks in advance,
> Steve
--------------030606070207060308090001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Steve,<br>
<br>
The resolved schema is the original schema without a changed
namespace. You need call getIncorporatedSchema to access the cloned
version that has the namespace retargeted.<br>
<br>
<br>
Steve Speicher wrote:
<blockquote cite="midd01rld$ete$1@www.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
I've attached a simple plugin that illustrates the problem.<br>
<br>
Basically, I have an included schema that defines 1 complex type. The
including schema has only an element declaration of type from the
included schema. I am unable to locate an appropriate API call to get
matching complex type defintions. This appears to be true for other
types of references too: simple types, element references, etc. My
assumption is that the element declarations type reference would have
returned the same object representing the complex type definition (as
it does when they are defined in the same file)<br>
<br>
Note: the DO match if I add <tt>'xmlns:contact=<a
class="moz-txt-link-rfc2396E" href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
</tt><tt>targetNamespace=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>'</tt>
to the
included schema. The schema validates as is. I don't have the luxury
of changing of my schemas to have the added schema attributes.<br>
<br>
Here's the top-level schema (also included in the ZIP):<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E"
href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
xmlns:contact=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
xmlns:cntadv=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact/advanced">"http://www.ibm.com/contact/advanced"</a>
targetNamespace=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a> </tt><br>
<tt> elementFormDefault="qualified"></tt><br>
<tt> <include schemaLocation="Contact_include.xsd"/></tt><br>
<tt> <element name="Contact" type="contact:ContactType"/></tt><br>
<tt></schema></tt><br>
</blockquote>
Here's the included schema:<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E"
href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
elementFormDefault="qualified"></tt><br>
<tt> <complexType name="ContactType"></tt><br>
<tt> <sequence></tt><br>
<tt> <element name="Name" type="string"/></tt><br>
<tt> <element name="Email" type="string"/></tt><br>
<tt> </sequence></tt><br>
<tt> <attribute name="gender" type="string"/></tt><br>
<tt> </complexType></tt><br>
<tt></schema><br>
</tt></blockquote>
The test program shows that XSDComplexTypeDefinition instance from the
XSDInclude.getResolvedSchema().getContents() does NOT equal (via the
"==" operator) XSDElementDeclaration.getTypeDefinition().<br>
<br>
This affects me as I depend on the hashCodes to be the same to ensure I
don't reconstruct more that I need.<br>
<br>
Note about the sample code:<br>
- Adds a menu option to context menu for *.xsd called "Parse XSD with
Include"<br>
<br>
Thanks in advance,<br>
Steve<br>
</blockquote>
<br>
</body>
</html>
--------------030606070207060308090001--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Resolving TypeDefinitions from <xsd:include> doesn't match TypeDefintion from element decl [message #594386 is a reply to message #58424] |
Wed, 02 March 2005 13:40 |
|
This is a multi-part message in MIME format.
--------------060307030206010309080709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
Thanks. That did the trick.
Ed Merks wrote:
> Steve,
>
> The resolved schema is the original schema without a changed
> namespace. You need call getIncorporatedSchema to access the cloned
> version that has the namespace retargeted.
>
>
> Steve Speicher wrote:
>
>> I've attached a simple plugin that illustrates the problem.
>>
>> Basically, I have an included schema that defines 1 complex type.
>> The including schema has only an element declaration of type from the
>> included schema. I am unable to locate an appropriate API call to
>> get matching complex type defintions. This appears to be true for
>> other types of references too: simple types, element references,
>> etc. My assumption is that the element declarations type reference
>> would have returned the same object representing the complex type
>> definition (as it does when they are defined in the same file)
>>
>> Note: the DO match if I add
>> 'xmlns:contact="http://www.ibm.com/contact"
>> targetNamespace="http://www.ibm.com/contact"' to the included
>> schema. The schema validates as is. I don't have the luxury of
>> changing of my schemas to have the added schema attributes.
>>
>> Here's the top-level schema (also included in the ZIP):
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <schema xmlns="http://www.w3.org/2001/XMLSchema"
>> xmlns:contact="http://www.ibm.com/contact"
>> xmlns:cntadv="http://www.ibm.com/contact/advanced"
>> targetNamespace="http://www.ibm.com/contact"
>> elementFormDefault="qualified">
>> <include schemaLocation="Contact_include.xsd"/>
>> <element name="Contact" type="contact:ContactType"/>
>> </schema>
>>
>> Here's the included schema:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <schema xmlns="http://www.w3.org/2001/XMLSchema"
>> elementFormDefault="qualified">
>> <complexType name="ContactType">
>> <sequence>
>> <element name="Name" type="string"/>
>> <element name="Email" type="string"/>
>> </sequence>
>> <attribute name="gender" type="string"/>
>> </complexType>
>> </schema>
>>
>> The test program shows that XSDComplexTypeDefinition instance from
>> the XSDInclude.getResolvedSchema().getContents() does NOT equal (via
>> the "==" operator) XSDElementDeclaration.getTypeDefinition().
>>
>> This affects me as I depend on the hashCodes to be the same to ensure
>> I don't reconstruct more that I need.
>>
>> Note about the sample code:
>> - Adds a menu option to context menu for *.xsd called "Parse XSD
>> with Include"
>>
>> Thanks in advance,
>> Steve
>
>
--------------060307030206010309080709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
Thanks. That did the trick.<br>
<br>
Ed Merks wrote:
<blockquote cite="midd022j9$lgb$1@www.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Steve,<br>
<br>
The resolved schema is the original schema without a changed
namespace. You need call getIncorporatedSchema to access the cloned
version that has the namespace retargeted.<br>
<br>
<br>
Steve Speicher wrote:
<blockquote cite="midd01rld$ete$1@www.eclipse.org" type="cite">
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
I've attached a simple plugin that illustrates the problem.<br>
<br>
Basically, I have an included schema that defines 1 complex type. The
including schema has only an element declaration of type from the
included schema. I am unable to locate an appropriate API call to get
matching complex type defintions. This appears to be true for other
types of references too: simple types, element references, etc. My
assumption is that the element declarations type reference would have
returned the same object representing the complex type definition (as
it does when they are defined in the same file)<br>
<br>
Note: the DO match if I add <tt>'xmlns:contact=<a
class="moz-txt-link-rfc2396E" href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
</tt><tt>targetNamespace=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>'</tt>
to the
included schema. The schema validates as is. I don't have the luxury
of changing of my schemas to have the added schema attributes.<br>
<br>
Here's the top-level schema (also included in the ZIP):<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E"
href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
xmlns:contact=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a>
xmlns:cntadv=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact/advanced">"http://www.ibm.com/contact/advanced"</a>
targetNamespace=<a class="moz-txt-link-rfc2396E"
href="http://www.ibm.com/contact">"http://www.ibm.com/contact"</a> </tt><br>
<tt> elementFormDefault="qualified"></tt><br>
<tt> <include schemaLocation="Contact_include.xsd"/></tt><br>
<tt> <element name="Contact" type="contact:ContactType"/></tt><br>
<tt></schema></tt><br>
</blockquote>
Here's the included schema:<br>
<blockquote><tt><?xml version="1.0" encoding="UTF-8"?></tt><br>
<tt><schema xmlns=<a class="moz-txt-link-rfc2396E"
href="http://www.w3.org/2001/XMLSchema">"http://www.w3.org/2001/XMLSchema"</a>
elementFormDefault="qualified"></tt><br>
<tt> <complexType name="ContactType"></tt><br>
<tt> <sequence></tt><br>
<tt> <element name="Name" type="string"/></tt><br>
<tt> <element name="Email" type="string"/></tt><br>
<tt> </sequence></tt><br>
<tt> <attribute name="gender" type="string"/></tt><br>
<tt> </complexType></tt><br>
<tt></schema><br>
</tt></blockquote>
The test program shows that XSDComplexTypeDefinition instance from the
XSDInclude.getResolvedSchema().getContents() does NOT equal (via the
"==" operator) XSDElementDeclaration.getTypeDefinition().<br>
<br>
This affects me as I depend on the hashCodes to be the same to ensure I
don't reconstruct more that I need.<br>
<br>
Note about the sample code:<br>
- Adds a menu option to context menu for *.xsd called "Parse XSD with
Include"<br>
<br>
Thanks in advance,<br>
Steve<br>
</blockquote>
<br>
</blockquote>
</body>
</html>
--------------060307030206010309080709--
|
|
|
| Re: Resolving TypeDefinitions from <xsd:include> doesn't match TypeDefintion from element decl [message #594396 is a reply to message #58400] |
Mon, 07 March 2005 16:34 |
|
Hi,
I have a related issue that I can't seem to overcome. Basically I have
a root schema that includes 2 other schemas. One of the included
schemas happens to include the other included schema from the root schema.
Take for example I have root.xsd that looks like:
<schema ...>
<include schemaLocation="include1.xsd"/>
<include schemaLocation="include2.xsd"/>
..
</schema>
Where include1.xsd looks something like:
<schema ...>
<include schemaLocation="include2.xsd"/>
...
</schema>
It appears that the API gives me 2 different instances of XSDInclude for
the 2 different include2.xsd's. Though, the simple type definition I
have in in include2.xsd both have the same instance of
XSDSimpleTypeDefinition.
Is there a reason why I'm getting the 2 different instances of
XSDInclude? I can't seem to locate an API call that would give me just 1.
Thanks in advance for any help.
Steve
|
|
|
| Re: Resolving TypeDefinitions from <xsd:include> doesn't match TypeDefintion from element decl [message #594410 is a reply to message #58455] |
Tue, 08 March 2005 13:23 |
Ed Merks
Messages: 33184
Registered: July 2009 |
Senior Member |
|
|
Steve,
I'm not sure what the problem is. Clearly your example really does have
two different includes of the same schema so I would expect there to be
two XSDInclude instances that refer to the same XSDSchema instance.
Perhaps you simply need to collect all the unique XSDSchema instances?
Or perhaps you simply want to look at features like
XSDSchema.getTypeDefinitions which collects all the types from all the
schemas?
Steve Speicher wrote:
> Hi,
>
> I have a related issue that I can't seem to overcome. Basically I
> have a root schema that includes 2 other schemas. One of the included
> schemas happens to include the other included schema from the root
> schema.
>
> Take for example I have root.xsd that looks like:
>
> <schema ...>
> <include schemaLocation="include1.xsd"/>
> <include schemaLocation="include2.xsd"/>
> ..
> </schema>
>
> Where include1.xsd looks something like:
> <schema ...>
> <include schemaLocation="include2.xsd"/>
> ...
> </schema>
>
> It appears that the API gives me 2 different instances of XSDInclude
> for the 2 different include2.xsd's. Though, the simple type
> definition I have in in include2.xsd both have the same instance of
> XSDSimpleTypeDefinition.
>
> Is there a reason why I'm getting the 2 different instances of
> XSDInclude? I can't seem to locate an API call that would give me
> just 1.
>
> Thanks in advance for any help.
>
> Steve
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04045 seconds
] 
Search
Help
Register
Login
Home
