s some test cases are
choosing explicitly to validate in XSD 1.0 mode (e.g. see
ConditionalInclusionTests
<https://github.com/svanteschubert/xerces-j/blob/maven-prototype/src/test/java/org/apache/xerces/tests/ConditionalInclusionTests.java#L76>),
unfortunately, only for XSD 1.1 mo
Getting tired, just a quick correction:
1. Copied the tests of the "xml-schema-1.1-tests" git branch from "src"
to "*src/test/java*" in the "xml-schema-1.1-dev" branch
2. Copied the test files of the "xml-schema-1.1-tests" git branch fr
Dear Xerces-J users,
I enabled a prototype of Maven for Xerces-j on top of the
"xml-schema-1.1-dev" Git branch to build and test with Netbeans - any IDE
supporting Maven, see
https://github.com/svanteschubert/xerces-j/tree/maven-prototype
Aimed to change as little as possible at the
Test
--
Garvit Sharma
github.com/garvitlnmiit/
No Body is a Scholar by birth, its only hard work and strong determination
that makes him master.
Thanks for the help, I decided to keep using my own "error types", it
makes more sense when viewing the errors.
Best,
Yoann
On 4/5/10 12:38, Mukul Gandhi wrote:
I think, Xerces internally stores all error outcomes (for example, 4
errors it prints in this case), for a particular validation epi
I think, Xerces internally stores all error outcomes (for example, 4
errors it prints in this case), for a particular validation episode
and returns all these to the user. Which I think, is good in a way
because we know, what all things went wrong with a given validation
situation.
If designing an
to create a new (3rd)
>> alternative rule:
>> > type="myElement.error" />
>
> It seems to me, that a more appropriate way to define type
> alternatives for this example, is perhaps like, following:
>
>
>
>
>
>
>
> With
ample, is perhaps like, following:
With an element definition like above, if 1st two XPath expressions
evaluate to false, the element would become invalid (because, it then
maps to type, xs:error).
Whereas, if the 3rd alternative also has a test attribute (which
you've specified in
> message telling you that the assertion failed.
>
> Regards,
> Khaled
>
>
>
>
> From: Michael Glavassevich/Toronto/i...@ibmca To:
> j-users@xerces.apache.org Date: 05/03/2010 01:41 PM Subject: Re: XSD1.1
> alternative test and errors
> --
>
From:
Michael Glavassevich/Toronto/i...@ibmca
To:
j-users@xerces.apache.org
Date:
05/03/2010 01:41 PM
Subject:
Re: XSD1.1 alternative test and errors
Hi Yoann,
Are you using a binary built from the XML Schema 1.1 development branch
[1]? We're still working on implementing these features.
Hi Yoann,
Are you using a binary built from the XML Schema 1.1 development branch
[1]? We're still working on implementing these features. It's possible
support for xs:error isn't there yet or isn't correct. I haven't looked at
this much though. Khaled, Mukul and/or Hiranya would probably have mo
Dear all,
I am facing an issue while validating using XSD1.1.
I want to decide on the type of an element depending on one of its
attribute value:
Now that works, both types "myElement.value1" and "myElement.value2"
are complex types.
However, I realized that if I have @attribute = '
how the Reader is initialized or the
contents of the XML file that is being read.
You'll get the most help from people on this list if you post a simple,
stand-alone test case that reproduces the problem. Provide a simple XML
file, and a single class with a main method that can be run to show the
HI
I posted question earlier. Thanks Peter for answering...
Here is the details of the code when it happens...
While the code try to read the document it calls this XCBL class given
below.
Any help is appreciated.
thanks.
public class XCBL extends TPCXXmlWrapper {
public XCBL(Reader reader)
14 matches
Mail list logo
