Re: Re: Possible Bug: Xerces 2.12.1 for XML Validation with XSD 1.1 Schema under Java - Plain Text
JOHN Morris <[email protected]> Sun, 23 Aug 2020 09:43:02 +0100 (BST)
| Newsgroups | gmane.text.xml.xerces-j.user |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_1321974_2062556220.1598172182199 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Mukul, Thanks for your further comments. I think that the first steps in achieving convergence between the validation behaviour that you observe and mine is for me to try switching to jaxp.SourceValidator and to ensure that I am using the same environment as you. To that (second) end, I would ask you to provide a (Windows) batch file, embodying the environment that you use to run your tests (unless your tests were made using the environment in my batch file). I would also ask you which characters in my XML files were unable to be represented in the default UTF-8 encoding, in case they are the result typos that I haven't noticed. Many thanks once again for your patience. Best regards, John. > On 23 August 2020 at 07:46 Mukul Gandhi <[email protected]> wrote: > > On Sat, Aug 22, 2020 at 10:27 PM JOHN Morris <[email protected]> wrote: > > > > > > I note your reference to using jaxp.SourceValidator/ I'm not sure whether you are claiming that, if you use that, you don't see any of the problems that I have highlighted(?) > > > > > I didn't mean that. Its just that, my personal preference to do XSD validation with Xerces-J, for your examples, is to use Xerces-J sample jaxp.SourceValidator. > > > > > > I find that seemingly good XML constructs cause validation error WHEN THOSE XML CONSTRUCTS OCCUR AT CERTAIN PROBLEMATIC LINE NUMBERS e.g. line 44, in my test1.xml file). However, those exact same constructs DO NOT trigger errors if they appear at different XML line numbers. For example, if I insert an XML comment line before one of these constructs,formerly appearing at a problematic line number, so that it now appears at the subsequent line number, it no longer triggers an error!!! That was what the second test file was supposed to illustrate. > > > > > I don't experience these things. For me, both of your XML documents (test1.xml and test2.xml) when validated by your XSD document (test.xsd), produces same sort of errors. My validation attempts using Xerces-J, produces about 9 validation errors for both of the XML documents that are validated. I'm not sure, what is different at your side. > > > > > > As for using xs:pattern, my imagination was not rich enough to know how to achieve the same effect as I was trying to get with 'matches' but now with xs:pattern. Have you been able to visualise how to do that? > > > > > Let's say you wish to have <xs:assert test="if (./text()[matches(.,'^(install\.xml)$')]) then @file else true()"/> written using xs:pattern instead of XPath 2.0 'matches' function. > > Following should be the steps to do this, > > 1) Create an XSD simple type definition > > <xs:simpleType name="StringType1"> > <xs:restriction base="xs:string"> > <xs:pattern value="regex_expr"/> > <xs:restriction> > </xs:simpleType> > > 2) Write the xs:assert as following > > <xs:assert test="if (./text() castable as StringType1) then @file else true()"/> > > (the above suggested XSD fragments, are not tested from my side) > > Another minor point. I had to add the following XML prolog to your XML documents that are to be validated, > <?xml version="1.0" encoding="ISO-8859-1"?> > > (your XML documents contain few characters, that cannot be represented with the default encoding UTF-8). > > > > -- > Regards, > Mukul Gandhi > ------=_Part_1321974_2062556220.1598172182199 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html><head> <meta charset=3D"UTF-8"> </head><body><p>Hi Mukul,<br></p><p>Thanks for your further comments.<br></= p><p>I think that the first steps in achieving convergence between the vali= dation behaviour that you observe and mine is for me to try switching to ja= xp.SourceValidator and to ensure that I am using the same environment as yo= u. To that (second) end, I would ask you to provide a (Windows) batch file,= embodying the environment that you use to run your tests (unless your test= s were made using the environment in my batch file).<br></p><p>I would also= ask you which characters in my XML files were unable to be represented in = the default UTF-8 encoding, in case they are the result typos that I haven&= #39;t noticed.<br></p><p>Many thanks once again for your patience.<br></p><= p>Best regards,<br></p><p>John.<br></p><blockquote type=3D"cite">On 23 Augu= st 2020 at 07:46 Mukul Gandhi <[email protected]> wrote: <br> <br><= div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir= =3D"ltr"><div dir=3D"ltr">On Sat, Aug 22, 2020 at 10:27 PM JOHN Morris <= ;[email protected]> wrote: <br></div><div class=3D"ox-632= 9777d28-gmail_quote"><blockquote><u></u><div><p>I note your reference to us= ing jaxp.SourceValidator/ I'm not sure whether you are claiming that, i= f you use that, you don't see any of the problems that I have highlight= ed(?)<br></p></div></blockquote><div>I didn't mean that. Its just that,= my personal preference to do XSD validation with Xerces-J, for your e= xamples, is to use Xerces-J sample jaxp.SourceValidator.</div><blockquote><= div><p>I find that seemingly good XML constructs cause validation error WHE= N THOSE XML CONSTRUCTS OCCUR AT CERTAIN PROBLEMATIC LINE NUMBERS e.g. line = 44, in my test1.xml file). However, those exact same constructs DO NOT trig= ger errors if they appear at different XML line numbers. For example, if I = insert an XML comment line before one of these constructs,formerly appearin= g at a problematic line number, so that it now appears at the subsequent li= ne number, it no longer triggers an error!!! That was what the second test = file was supposed to illustrate.<br></p></div></blockquote><div>I don't= experience these things. For me, both of your XML documents (test1.xml and= test2.xml) when validated by your XSD document (test.xsd), produces same s= ort of errors. My validation attempts using Xerces-J, produces about 9 vali= dation errors for both of the XML documents that are validated. I'm not= sure, what is different at your side.</div><blockquote><div><p>As for usin= g xs:pattern, my imagination was not rich enough to know how to achieve the= same effect as I was trying to get with 'matches' but now with xs:= pattern. Have you been able to visualise how to do that?</p></div></blockqu= ote><div>Let's say you wish to have <xs:assert test=3D"if = (./text()[matches(.,'^(install\.xml)$')]) then @file else true()= 4;/> written using xs:pattern instead of XPath 2.0 'matches' fu= nction.</div><div><br></div><div>Following should be the steps to do this,<= /div><div><br></div><div>1) Create an XSD simple type definition <br></div>= <div><br></div><div><xs:simpleType name=3D"StringType1"></d= iv><div>    <xs:restriction base=3D"xs:string"></= div><div>         <xs:pattern value=3D"reg= ex_expr"/></div><div>    <xs:restriction></div><d= iv></xs:simpleType></div><div><br></div><div>2) Write the xs:assert= as following</div><div><br></div><div><xs:assert test=3D"if (./tex= t() castable as StringType1) then @file else true()"/> <br></div><d= iv><br></div><div>(the above suggested XSD fragments, are not tested from m= y side)</div><div><br></div><div>Another minor point. I had to add the foll= owing XML prolog to your XML documents that are to be validated,</div><div>= <?xml version=3D"1.0" encoding=3D"ISO-8859-1"?> <br= ></div><div><br></div><div>(your XML documents contain few characters, that= cannot be represented with the default encoding UTF-8).</div><div><br></di= v><div> </div></div><div><br></div>-- <br><div dir=3D"ltr" class=3D"ox= -6329777d28-gmail_signature"><div dir=3D"ltr"><div>Regards, <br>Mukul Gandh= i <br></div></div></div></div></div></div></div></div></blockquote></body><= /html> =20 ------=_Part_1321974_2062556220.1598172182199--