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 <muk...@apache.org> wrote: > > On Sat, Aug 22, 2020 at 10:27 PM JOHN Morris > <j.morri...@ntlworld.com.invalid> 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 >
