| Home » Archived » XML Schema Definition (XSD) » Bug in validation?
 Goto Forum:| 
| Bug in validation? [message #33614] | Tue, 25 November 2003 17:24  |  | 
| Eclipse User  |  |  |  |  | Ed, I'm still after this problem where my problem markers do not seem to be
 correctly getting cleaned up when doing a validate after fixing a problem in
 an schema.  Here is the scenario... Two Xsd files, one imports the other.
 Load them both into a ResourceSet and Validate.  I get no errors.  Delete
 the imported Xsd and run validation on the importing schema... I get an
 error (as expected).  Re-load the imported schema and re-run validation.  I
 still get validation errors when I wouldn't expect to....  I've attached a
 PdeJunit test that can be run.  The last test is failing where I re-add the
 imported XSD back into the ResourceSet and revalidate the importing schema.
 I still end up with validation errors.....
 
 Obviously you won't be able to run the test case as is since I can not
 send the models or the referenced Metamatrix utility class... but you should
 be able to capture the spirit of the problem with this test case ;)
 
 thanks,
 
 lp
 
 
 
 |  |  |  |  | 
| Re: Bug in validation? [message #33651 is a reply to message #33614] | Tue, 25 November 2003 18:32   |  | 
| Eclipse User  |  |  |  |  | Originally posted by: merks.ca.ibm.com 
 --------------3F6A288FBD1C346E8D762FE9
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 Lance,
 
 When in an earlier note I said:
 
 I've never tried unloading an XSDResourceImpl.  The complex
 include/import/redefine interdependencies between .xsd files makes
 unloading just one .xsd resource likely not to work well.
 
 I really wasn't kidding.  Rebuilding a valid XSD model after trashing just single
 ..xsd resource simply doesn't work unless it is the "root" schema, i.e., any .xsd that
 depends on the trashed .xsd will also need to be unloaded.  Features like element
 substitution groups even produce nasty back pointers from the group head out to group
 members because a group head is defined to act as a <choice> of all the members of
 the group; so if in doubt, unload it...
 
 
 Lance Phillips wrote:
 
 > Ed,
 >     I'm still after this problem where my problem markers do not seem to be
 > correctly getting cleaned up when doing a validate after fixing a problem in
 > an schema.  Here is the scenario... Two Xsd files, one imports the other.
 > Load them both into a ResourceSet and Validate.  I get no errors.  Delete
 > the imported Xsd and run validation on the importing schema... I get an
 > error (as expected).  Re-load the imported schema and re-run validation.  I
 > still get validation errors when I wouldn't expect to....  I've attached a
 > PdeJunit test that can be run.  The last test is failing where I re-add the
 > imported XSD back into the ResourceSet and revalidate the importing schema.
 > I still end up with validation errors.....
 >
 >     Obviously you won't be able to run the test case as is since I can not
 > send the models or the referenced Metamatrix utility class... but you should
 > be able to capture the spirit of the problem with this test case ;)
 >
 > thanks,
 >
 > lp
 >
 >                                 Name: PdeTestXsdValidation.java
 >    PdeTestXsdValidation.java    Type: unspecified type (application/octet-stream)
 >                             Encoding: x-uuencode
 
 --------------3F6A288FBD1C346E8D762FE9
 Content-Type: text/html; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 <html>
 Lance,
 <p>When in an earlier note I said:
 <blockquote>I've never tried unloading an XSDResourceImpl.  The complex
 include/import/redefine interdependencies between .xsd files makes unloading
 just one .xsd resource likely not to work well.</blockquote>
 I really wasn't kidding.  Rebuilding a valid XSD model after trashing
 just single .xsd resource simply doesn't work unless it is the "root" schema,
 i.e., any .xsd that depends on the trashed .xsd will also need to be unloaded. 
 Features like element substitution groups even produce nasty back pointers
 from the group head out to group members because a group head is defined
 to act as a <choice> of all the members of the group; so if in doubt,
 unload it...
 <br> 
 <p>Lance Phillips wrote:
 <blockquote TYPE=CITE>Ed,
 <br>    I'm still after this problem where my problem markers
 do not seem to be
 <br>correctly getting cleaned up when doing a validate after fixing a problem
 in
 <br>an schema.  Here is the scenario... Two Xsd files, one imports
 the other.
 <br>Load them both into a ResourceSet and Validate.  I get no errors. 
 Delete
 <br>the imported Xsd and run validation on the importing schema... I get
 an
 <br>error (as expected).  Re-load the imported schema and re-run validation. 
 I
 <br>still get validation errors when I wouldn't expect to....  I've
 attached a
 <br>PdeJunit test that can be run.  The last test is failing where
 I re-add the
 <br>imported XSD back into the ResourceSet and revalidate the importing
 schema.
 <br>I still end up with validation errors.....
 <p>    Obviously you won't be able to run the test case
 as is since I can not
 <br>send the models or the referenced Metamatrix utility class... but you
 should
 <br>be able to capture the spirit of the problem with this test case ;)
 <p>thanks,
 <p>lp
 <p>                                     
 Name: PdeTestXsdValidation.java
 <br>   PdeTestXsdValidation.java    Type: unspecified
 type (application/octet-stream)
 <br>                                
 Encoding: x-uuencode</blockquote>
 </html>
 
 --------------3F6A288FBD1C346E8D762FE9--
 |  |  |  |  | 
| Re: Bug in validation? [message #33680 is a reply to message #33651] | Wed, 26 November 2003 08:52   |  | 
| Eclipse User  |  |  |  |  | This is a multi-part message in MIME format. 
 ------=_NextPart_000_000D_01C3B3F2.30886AD0
 Content-Type: text/plain;
 charset="iso-8859-1"
 Content-Transfer-Encoding: quoted-printable
 
 Wow, that certainly is bad news.  I think this is the first time you've =
 ever given us a really bad answer ;)
 
 We run this builder as validation.  Thus it is very nice for the user to =
 be able to run validation PRIOR to performing a save.  However, if I =
 have to unload and reload all schemas to ensure validation is correct =
 we'll have to force the user to save any XSD files prior to performing =
 validation so that I can blow them all away and reload them.  That is =
 really going to suck for performance as well!  If I unload a schema and =
 reload it, do I even need to do the validation, or can I simply ask for =
 the diagnostics?  Also, what is the impact of unloading / reloading an =
 XSD that is open in an editor... will the editor behave or barf?
 
 thanks,
 
 lp
 "Ed Merks" <merks@ca.ibm.com> wrote in message =
 news:3FC3E68A.8079E6F3@ca.ibm.com...
 Lance,=20
 When in an earlier note I said:=20
 
 I've never tried unloading an XSDResourceImpl.  The complex =
 include/import/redefine interdependencies between .xsd files makes =
 unloading just one .xsd resource likely not to work well.
 I really wasn't kidding.  Rebuilding a valid XSD model after trashing =
 just single .xsd resource simply doesn't work unless it is the "root" =
 schema, i.e., any .xsd that depends on the trashed .xsd will also need =
 to be unloaded.  Features like element substitution groups even produce =
 nasty back pointers from the group head out to group members because a =
 group head is defined to act as a <choice> of all the members of the =
 group; so if in doubt, unload it...=20
 =20
 Lance Phillips wrote:=20
 
 Ed,=20
 I'm still after this problem where my problem markers do not =
 seem to be=20
 correctly getting cleaned up when doing a validate after fixing a =
 problem in=20
 an schema.  Here is the scenario... Two Xsd files, one imports the =
 other.=20
 Load them both into a ResourceSet and Validate.  I get no errors.  =
 Delete=20
 the imported Xsd and run validation on the importing schema... I get =
 an=20
 error (as expected).  Re-load the imported schema and re-run =
 validation.  I=20
 still get validation errors when I wouldn't expect to....  I've =
 attached a=20
 PdeJunit test that can be run.  The last test is failing where I =
 re-add the=20
 imported XSD back into the ResourceSet and revalidate the importing =
 schema.=20
 I still end up with validation errors.....=20
 Obviously you won't be able to run the test case as is since I =
 can not=20
 send the models or the referenced Metamatrix utility class... but =
 you should=20
 be able to capture the spirit of the problem with this test case ;)=20
 
 thanks,=20
 
 lp=20
 
 Name: PdeTestXsdValidation.java=20
 PdeTestXsdValidation.java    Type: unspecified type =
 (application/octet-stream)=20
 Encoding: x-uuencode
 
 ------=_NextPart_000_000D_01C3B3F2.30886AD0
 Content-Type: text/html;
 charset="iso-8859-1"
 Content-Transfer-Encoding: quoted-printable
 
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <HTML><HEAD>
 <META http-equiv=3DContent-Type content=3D"text/html; =
 charset=3Diso-8859-1">
 <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
 <STYLE></STYLE>
 </HEAD>
 <BODY bgColor=3D#ffffff>
 <DIV><FONT face=3DArial size=3D2>Wow, that certainly is bad news.  =
 I think this=20
 is the first time you've ever given us a really bad answer =
 ;)</FONT></DIV>
 <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
 <DIV><FONT face=3DArial size=3D2>We run this builder =
 as validation.  Thus=20
 it is very nice for the user to be able to run validation PRIOR to =
 performing a=20
 save.  However, if I have to unload and reload all schemas to =
 ensure=20
 validation is correct we'll have to force the user to save any XSD files =
 prior=20
 to performing validation so that I can blow them all away and reload =
 them. =20
 That is really going to suck for performance as well!  If I unload =
 a schema=20
 and reload it, do I even need to do the validation, or can I simply ask =
 for the=20
 diagnostics?  Also, what is the impact of unloading / reloading an =
 XSD that=20
 is open in an editor... will the editor behave or barf?</FONT></DIV>
 <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
 <DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
 <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
 <DIV><FONT face=3DArial size=3D2>lp</FONT></DIV>
 <BLOCKQUOTE dir=3Dltr=20
 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
 BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
 <DIV>"Ed Merks" <<A =
 href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
 wrote in message <A=20
 =
 href=3D"news:3FC3E68A.8079E6F3@ca.ibm.com">news:3FC3E68A.8079E6F3@ca.ibm.=
 com</A>...</DIV>Lance,=20
 
 <P>When in an earlier note I said:=20
 <BLOCKQUOTE>I've never tried unloading an XSDResourceImpl.  The =
 complex=20
 include/import/redefine interdependencies between .xsd files makes =
 unloading=20
 just one .xsd resource likely not to work well.</BLOCKQUOTE>I really =
 wasn't=20
 kidding.  Rebuilding a valid XSD model after trashing just single =
 ..xsd=20
 resource simply doesn't work unless it is the "root" schema, i.e., any =
 ..xsd=20
 that depends on the trashed .xsd will also need to be unloaded.  =
 Features=20
 like element substitution groups even produce nasty back pointers from =
 the=20
 group head out to group members because a group head is defined to act =
 as a=20
 <choice> of all the members of the group; so if in doubt, unload =
 it...=20
 <BR> =20
 <P>Lance Phillips wrote:=20
 <BLOCKQUOTE TYPE=3D"CITE">Ed, <BR>    I'm still after =
 this=20
 problem where my problem markers do not seem to be <BR>correctly =
 getting=20
 cleaned up when doing a validate after fixing a problem in <BR>an=20
 schema.  Here is the scenario... Two Xsd files, one imports the =
 other.=20
 <BR>Load them both into a ResourceSet and Validate.  I get no=20
 errors.  Delete <BR>the imported Xsd and run validation on the=20
 importing schema... I get an <BR>error (as expected).  Re-load =
 the=20
 imported schema and re-run validation.  I <BR>still get =
 validation=20
 errors when I wouldn't expect to....  I've attached a =
 <BR>PdeJunit test=20
 that can be run.  The last test is failing where I re-add the=20
 <BR>imported XSD back into the ResourceSet and revalidate the =
 importing=20
 schema. <BR>I still end up with validation errors.....=20
 <P>    Obviously you won't be able to run the test =
 case as is=20
 since I can not <BR>send the models or the referenced Metamatrix =
 utility=20
 class... but you should <BR>be able to capture the spirit of the =
 problem=20
 with this test case ;)=20
 <P>thanks,=20
 <P>lp=20
 =
 <P>             &nbs=
 p;     &nbs p;     &nbs p=
 ;       ; =20
 Name: PdeTestXsdValidation.java <BR>  =20
 PdeTestXsdValidation.java    Type: unspecified type=20
 (application/octet-stream)=20
 =
 <BR>             &nb=
 sp;     &nb sp;     &nb s=
 p;   =20
 Encoding: x-uuencode</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
 
 ------=_NextPart_000_000D_01C3B3F2.30886AD0--
 |  |  |  |  | 
| Re: Bug in validation? [message #33706 is a reply to message #33680] | Wed, 26 November 2003 12:19  |  | 
| Eclipse User  |  |  |  |  | Originally posted by: merks.ca.ibm.com 
 --------------4EFC86FE32D865D323BE7F0A
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 Lance,
 
 I tell it like it is... ;-)
 
 XML Schema as some horrible dependency issues between files.  A schema
 that is valid in one context may not be valid in another.  In fact,
 simply by resolving an import, you may go from having a valid schema to
 having an invalid one.  There really isn't a such notion as global
 correctness, it's all a relative thing given a set of root schemas.
 I'm not really sure what kind of global state you are maintaining or the
 context in which you are doing the unload.  Each sample editor maintains
 it's own local state and it does no listening for workbench deltas, so
 it won't know that you've saved anything.
 
 
 Lance Phillips wrote:
 
 > Wow, that certainly is bad news.  I think this is the first time
 > you've ever given us a really bad answer ;) We run this builder as
 > validation.  Thus it is very nice for the user to be able to run
 > validation PRIOR to performing a save.  However, if I have to unload
 > and reload all schemas to ensure validation is correct we'll have to
 > force the user to save any XSD files prior to performing validation so
 > that I can blow them all away and reload them.  That is really going
 > to suck for performance as well!  If I unload a schema and reload it,
 > do I even need to do the validation, or can I simply ask for the
 > diagnostics?  Also, what is the impact of unloading / reloading an XSD
 > that is open in an editor... will the editor behave or
 > barf? thanks, lp
 >
 >      "Ed Merks" <merks@ca.ibm.com> wrote in message
 >      news:3FC3E68A.8079E6F3@ca.ibm.com...Lance,
 >
 >      When in an earlier note I said:
 >
 >           I've never tried unloading an XSDResourceImpl.
 >           The complex include/import/redefine
 >           interdependencies between .xsd files makes
 >           unloading just one .xsd resource likely not to
 >           work well.
 >
 >      I really wasn't kidding.  Rebuilding a valid XSD model after
 >      trashing just single .xsd resource simply doesn't work
 >      unless it is the "root" schema, i.e., any .xsd that depends
 >      on the trashed .xsd will also need to be unloaded.  Features
 >      like element substitution groups even produce nasty back
 >      pointers from the group head out to group members because a
 >      group head is defined to act as a <choice> of all the
 >      members of the group; so if in doubt, unload it...
 >
 >
 >      Lance Phillips wrote:
 >
 >     > Ed,
 >     >     I'm still after this problem where my problem markers
 >     > do not seem to be
 >     > correctly getting cleaned up when doing a validate after
 >     > fixing a problem in
 >     > an schema.  Here is the scenario... Two Xsd files, one
 >     > imports the other.
 >     > Load them both into a ResourceSet and Validate.  I get no
 >     > errors.  Delete
 >     > the imported Xsd and run validation on the importing
 >     > schema... I get an
 >     > error (as expected).  Re-load the imported schema and
 >     > re-run validation.  I
 >     > still get validation errors when I wouldn't expect to....
 >     > I've attached a
 >     > PdeJunit test that can be run.  The last test is failing
 >     > where I re-add the
 >     > imported XSD back into the ResourceSet and revalidate the
 >     > importing schema.
 >     > I still end up with validation errors.....
 >     >
 >     >     Obviously you won't be able to run the test case as is
 >     > since I can not
 >     > send the models or the referenced Metamatrix utility
 >     > class... but you should
 >     > be able to capture the spirit of the problem with this
 >     > test case ;)
 >     >
 >     > thanks,
 >     >
 >     > lp
 >     >
 >     >                                 Name:
 >     > PdeTestXsdValidation.java
 >     >    PdeTestXsdValidation.java    Type: unspecified type
 >     > (application/octet-stream)
 >     >                             Encoding: x-uuencode
 >
 
 --------------4EFC86FE32D865D323BE7F0A
 Content-Type: text/html; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 <html>
 <body bgcolor="#FFFFFF">
 Lance,
 <p>I tell it like it is... ;-)
 <p>XML Schema as some horrible dependency issues between files.  A
 schema that is valid in one context may not be valid in another. 
 In fact, simply by resolving an import, you may go from having a valid
 schema to having an invalid one.  There really isn't a such notion
 as global correctness, it's all a relative thing given a set of root schemas.  
 I'm not really sure what kind of global state you are maintaining or the
 context in which you are doing the unload.  Each sample editor maintains
 it's own local state and it does no listening for workbench deltas, so
 it won't know that you've saved anything.
 <br> 
 <p>Lance Phillips wrote:
 <blockquote TYPE=CITE><style></style>
 <font face="Arial"><font size=-1>Wow,
 that certainly is bad news.  I think this is the first time you've
 ever given us a really bad answer ;)</font></font> <font face="Arial"><font size=-1>We
 run this builder as validation.  Thus it is very nice for the user
 to be able to run validation PRIOR to performing a save.  However,
 if I have to unload and reload all schemas to ensure validation is correct
 we'll have to force the user to save any XSD files prior to performing
 validation so that I can blow them all away and reload them.  That
 is really going to suck for performance as well!  If I unload a schema
 and reload it, do I even need to do the validation, or can I simply ask
 for the diagnostics?  Also, what is the impact of unloading / reloading
 an XSD that is open in an editor... will the editor behave or barf?</font></font> <font face="Arial"><font size=-1>thanks,</font></font> <font face="Arial"><font size=-1>lp</font></font>
 <blockquote dir=ltr
 style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed
 Merks" <<a href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>> wrote
 in message <a href="news:3FC3E68A.8079E6F3@ca.ibm.com">news:3FC3E68A.8079E6F3@ca.ibm.com</a>...Lance,
 <p>When in an earlier note I said:
 <blockquote>I've never tried unloading an XSDResourceImpl.  The complex
 include/import/redefine interdependencies between .xsd files makes unloading
 just one .xsd resource likely not to work well.</blockquote>
 I really wasn't kidding.  Rebuilding a valid XSD model after trashing
 just single .xsd resource simply doesn't work unless it is the "root" schema,
 i.e., any .xsd that depends on the trashed .xsd will also need to be unloaded. 
 Features like element substitution groups even produce nasty back pointers
 from the group head out to group members because a group head is defined
 to act as a <choice> of all the members of the group; so if in doubt,
 unload it...
 <br> 
 <p>Lance Phillips wrote:
 <blockquote TYPE="CITE">Ed,
 <br>    I'm still after this problem where my problem markers
 do not seem to be
 <br>correctly getting cleaned up when doing a validate after fixing a problem
 in
 <br>an schema.  Here is the scenario... Two Xsd files, one imports
 the other.
 <br>Load them both into a ResourceSet and Validate.  I get no errors. 
 Delete
 <br>the imported Xsd and run validation on the importing schema... I get
 an
 <br>error (as expected).  Re-load the imported schema and re-run validation. 
 I
 <br>still get validation errors when I wouldn't expect to....  I've
 attached a
 <br>PdeJunit test that can be run.  The last test is failing where
 I re-add the
 <br>imported XSD back into the ResourceSet and revalidate the importing
 schema.
 <br>I still end up with validation errors.....
 <p>    Obviously you won't be able to run the test case
 as is since I can not
 <br>send the models or the referenced Metamatrix utility class... but you
 should
 <br>be able to capture the spirit of the problem with this test case ;)
 <p>thanks,
 <p>lp
 <p>                                     
 Name: PdeTestXsdValidation.java
 <br>   PdeTestXsdValidation.java    Type: unspecified
 type (application/octet-stream)
 <br>                                
 Encoding: x-uuencode</blockquote>
 </blockquote>
 </blockquote>
 
 </body>
 </html>
 
 --------------4EFC86FE32D865D323BE7F0A--
 |  |  |  |  | 
| Re: Bug in validation? [message #581139 is a reply to message #33614] | Tue, 25 November 2003 18:32  |  | 
| Eclipse User  |  |  |  |  | --------------3F6A288FBD1C346E8D762FE9 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 Lance,
 
 When in an earlier note I said:
 
 I've never tried unloading an XSDResourceImpl.  The complex
 include/import/redefine interdependencies between .xsd files makes
 unloading just one .xsd resource likely not to work well.
 
 I really wasn't kidding.  Rebuilding a valid XSD model after trashing just single
 ..xsd resource simply doesn't work unless it is the "root" schema, i.e., any .xsd that
 depends on the trashed .xsd will also need to be unloaded.  Features like element
 substitution groups even produce nasty back pointers from the group head out to group
 members because a group head is defined to act as a <choice> of all the members of
 the group; so if in doubt, unload it...
 
 
 Lance Phillips wrote:
 
 > Ed,
 >     I'm still after this problem where my problem markers do not seem to be
 > correctly getting cleaned up when doing a validate after fixing a problem in
 > an schema.  Here is the scenario... Two Xsd files, one imports the other.
 > Load them both into a ResourceSet and Validate.  I get no errors.  Delete
 > the imported Xsd and run validation on the importing schema... I get an
 > error (as expected).  Re-load the imported schema and re-run validation.  I
 > still get validation errors when I wouldn't expect to....  I've attached a
 > PdeJunit test that can be run.  The last test is failing where I re-add the
 > imported XSD back into the ResourceSet and revalidate the importing schema.
 > I still end up with validation errors.....
 >
 >     Obviously you won't be able to run the test case as is since I can not
 > send the models or the referenced Metamatrix utility class... but you should
 > be able to capture the spirit of the problem with this test case ;)
 >
 > thanks,
 >
 > lp
 >
 >                                 Name: PdeTestXsdValidation.java
 >    PdeTestXsdValidation.java    Type: unspecified type (application/octet-stream)
 >                             Encoding: x-uuencode
 
 --------------3F6A288FBD1C346E8D762FE9
 Content-Type: text/html; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 <html>
 Lance,
 <p>When in an earlier note I said:
 <blockquote>I've never tried unloading an XSDResourceImpl.  The complex
 include/import/redefine interdependencies between .xsd files makes unloading
 just one .xsd resource likely not to work well.</blockquote>
 I really wasn't kidding.  Rebuilding a valid XSD model after trashing
 just single .xsd resource simply doesn't work unless it is the "root" schema,
 i.e., any .xsd that depends on the trashed .xsd will also need to be unloaded. 
 Features like element substitution groups even produce nasty back pointers
 from the group head out to group members because a group head is defined
 to act as a <choice> of all the members of the group; so if in doubt,
 unload it...
 <br> 
 <p>Lance Phillips wrote:
 <blockquote TYPE=CITE>Ed,
 <br>    I'm still after this problem where my problem markers
 do not seem to be
 <br>correctly getting cleaned up when doing a validate after fixing a problem
 in
 <br>an schema.  Here is the scenario... Two Xsd files, one imports
 the other.
 <br>Load them both into a ResourceSet and Validate.  I get no errors. 
 Delete
 <br>the imported Xsd and run validation on the importing schema... I get
 an
 <br>error (as expected).  Re-load the imported schema and re-run validation. 
 I
 <br>still get validation errors when I wouldn't expect to....  I've
 attached a
 <br>PdeJunit test that can be run.  The last test is failing where
 I re-add the
 <br>imported XSD back into the ResourceSet and revalidate the importing
 schema.
 <br>I still end up with validation errors.....
 <p>    Obviously you won't be able to run the test case
 as is since I can not
 <br>send the models or the referenced Metamatrix utility class... but you
 should
 <br>be able to capture the spirit of the problem with this test case ;)
 <p>thanks,
 <p>lp
 <p>                                     
 Name: PdeTestXsdValidation.java
 <br>   PdeTestXsdValidation.java    Type: unspecified
 type (application/octet-stream)
 <br>                                
 Encoding: x-uuencode</blockquote>
 </html>
 
 --------------3F6A288FBD1C346E8D762FE9--
 |  |  |  |  | 
| Re: Bug in validation? [message #581159 is a reply to message #33651] | Wed, 26 November 2003 08:52  |  | 
| Eclipse User  |  |  |  |  | This is a multi-part message in MIME format. 
 ------=_NextPart_000_000D_01C3B3F2.30886AD0
 Content-Type: text/plain;
 charset="iso-8859-1"
 Content-Transfer-Encoding: quoted-printable
 
 Wow, that certainly is bad news.  I think this is the first time you've =
 ever given us a really bad answer ;)
 
 We run this builder as validation.  Thus it is very nice for the user to =
 be able to run validation PRIOR to performing a save.  However, if I =
 have to unload and reload all schemas to ensure validation is correct =
 we'll have to force the user to save any XSD files prior to performing =
 validation so that I can blow them all away and reload them.  That is =
 really going to suck for performance as well!  If I unload a schema and =
 reload it, do I even need to do the validation, or can I simply ask for =
 the diagnostics?  Also, what is the impact of unloading / reloading an =
 XSD that is open in an editor... will the editor behave or barf?
 
 thanks,
 
 lp
 "Ed Merks" <merks@ca.ibm.com> wrote in message =
 news:3FC3E68A.8079E6F3@ca.ibm.com...
 Lance,=20
 When in an earlier note I said:=20
 
 I've never tried unloading an XSDResourceImpl.  The complex =
 include/import/redefine interdependencies between .xsd files makes =
 unloading just one .xsd resource likely not to work well.
 I really wasn't kidding.  Rebuilding a valid XSD model after trashing =
 just single .xsd resource simply doesn't work unless it is the "root" =
 schema, i.e., any .xsd that depends on the trashed .xsd will also need =
 to be unloaded.  Features like element substitution groups even produce =
 nasty back pointers from the group head out to group members because a =
 group head is defined to act as a <choice> of all the members of the =
 group; so if in doubt, unload it...=20
 =20
 Lance Phillips wrote:=20
 
 Ed,=20
 I'm still after this problem where my problem markers do not =
 seem to be=20
 correctly getting cleaned up when doing a validate after fixing a =
 problem in=20
 an schema.  Here is the scenario... Two Xsd files, one imports the =
 other.=20
 Load them both into a ResourceSet and Validate.  I get no errors.  =
 Delete=20
 the imported Xsd and run validation on the importing schema... I get =
 an=20
 error (as expected).  Re-load the imported schema and re-run =
 validation.  I=20
 still get validation errors when I wouldn't expect to....  I've =
 attached a=20
 PdeJunit test that can be run.  The last test is failing where I =
 re-add the=20
 imported XSD back into the ResourceSet and revalidate the importing =
 schema.=20
 I still end up with validation errors.....=20
 Obviously you won't be able to run the test case as is since I =
 can not=20
 send the models or the referenced Metamatrix utility class... but =
 you should=20
 be able to capture the spirit of the problem with this test case ;)=20
 
 thanks,=20
 
 lp=20
 
 Name: PdeTestXsdValidation.java=20
 PdeTestXsdValidation.java    Type: unspecified type =
 (application/octet-stream)=20
 Encoding: x-uuencode
 
 ------=_NextPart_000_000D_01C3B3F2.30886AD0
 Content-Type: text/html;
 charset="iso-8859-1"
 Content-Transfer-Encoding: quoted-printable
 
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <HTML><HEAD>
 <META http-equiv=3DContent-Type content=3D"text/html; =
 charset=3Diso-8859-1">
 <META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
 <STYLE></STYLE>
 </HEAD>
 <BODY bgColor=3D#ffffff>
 <DIV><FONT face=3DArial size=3D2>Wow, that certainly is bad news.  =
 I think this=20
 is the first time you've ever given us a really bad answer =
 ;)</FONT></DIV>
 <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
 <DIV><FONT face=3DArial size=3D2>We run this builder =
 as validation.  Thus=20
 it is very nice for the user to be able to run validation PRIOR to =
 performing a=20
 save.  However, if I have to unload and reload all schemas to =
 ensure=20
 validation is correct we'll have to force the user to save any XSD files =
 prior=20
 to performing validation so that I can blow them all away and reload =
 them. =20
 That is really going to suck for performance as well!  If I unload =
 a schema=20
 and reload it, do I even need to do the validation, or can I simply ask =
 for the=20
 diagnostics?  Also, what is the impact of unloading / reloading an =
 XSD that=20
 is open in an editor... will the editor behave or barf?</FONT></DIV>
 <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
 <DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
 <DIV><FONT face=3DArial size=3D2></FONT> </DIV>
 <DIV><FONT face=3DArial size=3D2>lp</FONT></DIV>
 <BLOCKQUOTE dir=3Dltr=20
 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
 BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
 <DIV>"Ed Merks" <<A =
 href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
 wrote in message <A=20
 =
 href=3D"news:3FC3E68A.8079E6F3@ca.ibm.com">news:3FC3E68A.8079E6F3@ca.ibm.=
 com</A>...</DIV>Lance,=20
 
 <P>When in an earlier note I said:=20
 <BLOCKQUOTE>I've never tried unloading an XSDResourceImpl.  The =
 complex=20
 include/import/redefine interdependencies between .xsd files makes =
 unloading=20
 just one .xsd resource likely not to work well.</BLOCKQUOTE>I really =
 wasn't=20
 kidding.  Rebuilding a valid XSD model after trashing just single =
 ..xsd=20
 resource simply doesn't work unless it is the "root" schema, i.e., any =
 ..xsd=20
 that depends on the trashed .xsd will also need to be unloaded.  =
 Features=20
 like element substitution groups even produce nasty back pointers from =
 the=20
 group head out to group members because a group head is defined to act =
 as a=20
 <choice> of all the members of the group; so if in doubt, unload =
 it...=20
 <BR> =20
 <P>Lance Phillips wrote:=20
 <BLOCKQUOTE TYPE=3D"CITE">Ed, <BR>    I'm still after =
 this=20
 problem where my problem markers do not seem to be <BR>correctly =
 getting=20
 cleaned up when doing a validate after fixing a problem in <BR>an=20
 schema.  Here is the scenario... Two Xsd files, one imports the =
 other.=20
 <BR>Load them both into a ResourceSet and Validate.  I get no=20
 errors.  Delete <BR>the imported Xsd and run validation on the=20
 importing schema... I get an <BR>error (as expected).  Re-load =
 the=20
 imported schema and re-run validation.  I <BR>still get =
 validation=20
 errors when I wouldn't expect to....  I've attached a =
 <BR>PdeJunit test=20
 that can be run.  The last test is failing where I re-add the=20
 <BR>imported XSD back into the ResourceSet and revalidate the =
 importing=20
 schema. <BR>I still end up with validation errors.....=20
 <P>    Obviously you won't be able to run the test =
 case as is=20
 since I can not <BR>send the models or the referenced Metamatrix =
 utility=20
 class... but you should <BR>be able to capture the spirit of the =
 problem=20
 with this test case ;)=20
 <P>thanks,=20
 <P>lp=20
 =
 <P>             &nbs=
 p;     &nbs p;     &nbs p=
 ;       ; =20
 Name: PdeTestXsdValidation.java <BR>  =20
 PdeTestXsdValidation.java    Type: unspecified type=20
 (application/octet-stream)=20
 =
 <BR>             &nb=
 sp;     &nb sp;     &nb s=
 p;   =20
 Encoding: x-uuencode</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
 
 ------=_NextPart_000_000D_01C3B3F2.30886AD0--
 |  |  |  |  | 
| Re: Bug in validation? [message #581181 is a reply to message #33680] | Wed, 26 November 2003 12:19  |  | 
| Eclipse User  |  |  |  |  | --------------4EFC86FE32D865D323BE7F0A Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 Lance,
 
 I tell it like it is... ;-)
 
 XML Schema as some horrible dependency issues between files.  A schema
 that is valid in one context may not be valid in another.  In fact,
 simply by resolving an import, you may go from having a valid schema to
 having an invalid one.  There really isn't a such notion as global
 correctness, it's all a relative thing given a set of root schemas.
 I'm not really sure what kind of global state you are maintaining or the
 context in which you are doing the unload.  Each sample editor maintains
 it's own local state and it does no listening for workbench deltas, so
 it won't know that you've saved anything.
 
 
 Lance Phillips wrote:
 
 > Wow, that certainly is bad news.  I think this is the first time
 > you've ever given us a really bad answer ;) We run this builder as
 > validation.  Thus it is very nice for the user to be able to run
 > validation PRIOR to performing a save.  However, if I have to unload
 > and reload all schemas to ensure validation is correct we'll have to
 > force the user to save any XSD files prior to performing validation so
 > that I can blow them all away and reload them.  That is really going
 > to suck for performance as well!  If I unload a schema and reload it,
 > do I even need to do the validation, or can I simply ask for the
 > diagnostics?  Also, what is the impact of unloading / reloading an XSD
 > that is open in an editor... will the editor behave or
 > barf? thanks, lp
 >
 >      "Ed Merks" <merks@ca.ibm.com> wrote in message
 >      news:3FC3E68A.8079E6F3@ca.ibm.com...Lance,
 >
 >      When in an earlier note I said:
 >
 >           I've never tried unloading an XSDResourceImpl.
 >           The complex include/import/redefine
 >           interdependencies between .xsd files makes
 >           unloading just one .xsd resource likely not to
 >           work well.
 >
 >      I really wasn't kidding.  Rebuilding a valid XSD model after
 >      trashing just single .xsd resource simply doesn't work
 >      unless it is the "root" schema, i.e., any .xsd that depends
 >      on the trashed .xsd will also need to be unloaded.  Features
 >      like element substitution groups even produce nasty back
 >      pointers from the group head out to group members because a
 >      group head is defined to act as a <choice> of all the
 >      members of the group; so if in doubt, unload it...
 >
 >
 >      Lance Phillips wrote:
 >
 >     > Ed,
 >     >     I'm still after this problem where my problem markers
 >     > do not seem to be
 >     > correctly getting cleaned up when doing a validate after
 >     > fixing a problem in
 >     > an schema.  Here is the scenario... Two Xsd files, one
 >     > imports the other.
 >     > Load them both into a ResourceSet and Validate.  I get no
 >     > errors.  Delete
 >     > the imported Xsd and run validation on the importing
 >     > schema... I get an
 >     > error (as expected).  Re-load the imported schema and
 >     > re-run validation.  I
 >     > still get validation errors when I wouldn't expect to....
 >     > I've attached a
 >     > PdeJunit test that can be run.  The last test is failing
 >     > where I re-add the
 >     > imported XSD back into the ResourceSet and revalidate the
 >     > importing schema.
 >     > I still end up with validation errors.....
 >     >
 >     >     Obviously you won't be able to run the test case as is
 >     > since I can not
 >     > send the models or the referenced Metamatrix utility
 >     > class... but you should
 >     > be able to capture the spirit of the problem with this
 >     > test case ;)
 >     >
 >     > thanks,
 >     >
 >     > lp
 >     >
 >     >                                 Name:
 >     > PdeTestXsdValidation.java
 >     >    PdeTestXsdValidation.java    Type: unspecified type
 >     > (application/octet-stream)
 >     >                             Encoding: x-uuencode
 >
 
 --------------4EFC86FE32D865D323BE7F0A
 Content-Type: text/html; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 <html>
 <body bgcolor="#FFFFFF">
 Lance,
 <p>I tell it like it is... ;-)
 <p>XML Schema as some horrible dependency issues between files.  A
 schema that is valid in one context may not be valid in another. 
 In fact, simply by resolving an import, you may go from having a valid
 schema to having an invalid one.  There really isn't a such notion
 as global correctness, it's all a relative thing given a set of root schemas.  
 I'm not really sure what kind of global state you are maintaining or the
 context in which you are doing the unload.  Each sample editor maintains
 it's own local state and it does no listening for workbench deltas, so
 it won't know that you've saved anything.
 <br> 
 <p>Lance Phillips wrote:
 <blockquote TYPE=CITE><style></style>
 <font face="Arial"><font size=-1>Wow,
 that certainly is bad news.  I think this is the first time you've
 ever given us a really bad answer ;)</font></font> <font face="Arial"><font size=-1>We
 run this builder as validation.  Thus it is very nice for the user
 to be able to run validation PRIOR to performing a save.  However,
 if I have to unload and reload all schemas to ensure validation is correct
 we'll have to force the user to save any XSD files prior to performing
 validation so that I can blow them all away and reload them.  That
 is really going to suck for performance as well!  If I unload a schema
 and reload it, do I even need to do the validation, or can I simply ask
 for the diagnostics?  Also, what is the impact of unloading / reloading
 an XSD that is open in an editor... will the editor behave or barf?</font></font> <font face="Arial"><font size=-1>thanks,</font></font> <font face="Arial"><font size=-1>lp</font></font>
 <blockquote dir=ltr
 style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed
 Merks" <<a href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>> wrote
 in message <a href="news:3FC3E68A.8079E6F3@ca.ibm.com">news:3FC3E68A.8079E6F3@ca.ibm.com</a>...Lance,
 <p>When in an earlier note I said:
 <blockquote>I've never tried unloading an XSDResourceImpl.  The complex
 include/import/redefine interdependencies between .xsd files makes unloading
 just one .xsd resource likely not to work well.</blockquote>
 I really wasn't kidding.  Rebuilding a valid XSD model after trashing
 just single .xsd resource simply doesn't work unless it is the "root" schema,
 i.e., any .xsd that depends on the trashed .xsd will also need to be unloaded. 
 Features like element substitution groups even produce nasty back pointers
 from the group head out to group members because a group head is defined
 to act as a <choice> of all the members of the group; so if in doubt,
 unload it...
 <br> 
 <p>Lance Phillips wrote:
 <blockquote TYPE="CITE">Ed,
 <br>    I'm still after this problem where my problem markers
 do not seem to be
 <br>correctly getting cleaned up when doing a validate after fixing a problem
 in
 <br>an schema.  Here is the scenario... Two Xsd files, one imports
 the other.
 <br>Load them both into a ResourceSet and Validate.  I get no errors. 
 Delete
 <br>the imported Xsd and run validation on the importing schema... I get
 an
 <br>error (as expected).  Re-load the imported schema and re-run validation. 
 I
 <br>still get validation errors when I wouldn't expect to....  I've
 attached a
 <br>PdeJunit test that can be run.  The last test is failing where
 I re-add the
 <br>imported XSD back into the ResourceSet and revalidate the importing
 schema.
 <br>I still end up with validation errors.....
 <p>    Obviously you won't be able to run the test case
 as is since I can not
 <br>send the models or the referenced Metamatrix utility class... but you
 should
 <br>be able to capture the spirit of the problem with this test case ;)
 <p>thanks,
 <p>lp
 <p>                                     
 Name: PdeTestXsdValidation.java
 <br>   PdeTestXsdValidation.java    Type: unspecified
 type (application/octet-stream)
 <br>                                
 Encoding: x-uuencode</blockquote>
 </blockquote>
 </blockquote>
 
 </body>
 </html>
 
 --------------4EFC86FE32D865D323BE7F0A--
 |  |  |  | 
 
 
 Current Time: Fri Oct 31 19:41:32 EDT 2025 
 Powered by FUDForum . Page generated in 0.04454 seconds |