gmane.text.xml.xerces-j.user

RE: debugging tools?

Jim Barnett — 2013-05-09T17:56:48

I’m specifically looking for a way to trace the evaluation of the Xpath expressions inside a schema <assertion>.  The tools you point to don’t  mention such a capability, and if they have it, it must be based on some underlying functionality in Xerces, so I was hoping someone could show me where the hooks to such a tracing capability would be.   (the specific problem that in the example that I sent around is that I have an <assertion> that should be rejecting a specific element in the document, but it is not. )

Thanks,
Jim

From: Mark R Maxey [mailto:Mark_R_Maxey< at >raytheon.com]
Sent: Thursday, May 09, 2013 10:45 AM
To: j-users< at >xerces.apache.org
Subject: Re: debugging tools?

I've foxy oxygen<http://www.oxygenxml.com/> and XMLSpy<http://www.altova.com/xmlspy.html> to be very helpful.

Mark Maxey
[Inactive hide details for Jim Barnett ---05/09/2013 09:31:58 AM---Are there tools that will help me debug a complex assertion?]Jim Barnett ---05/09/2013 09:31:58 AM---Are there tools that will help

Re: debugging tools?

Mukul Gandhi — 2013-05-09T15:24:19

For the example you've posted, there's no compilation error with
<assert> XPath expression and the <assert> has returned true for the
XML instance document you've posted.

The <assert> you've cited seems to have a lengthy XPath expression.
Unless there's a strong reason to write such lengthy <assert> XPath
expressions, these should be refactored (for example, by breaking
these into multiple asserts) to have a reasonable logical complexity.

On Thu, May 9, 2013 at 7:42 PM, Jim Barnett <Jim.Barnett< at >genesyslab.com> wrote:

Re: debugging tools?

Mark R Maxey — 2013-05-09T14:45:23

I've foxy oxygen and XMLSpy to be very helpful.

Mark Maxey

From:Jim Barnett <Jim.Barnett< at >genesyslab.com>
To:"j-users< at >xerces.apache.org" <j-users< at >xerces.apache.org>
Date:05/09/2013 09:31 AM
Subject:debugging tools?

Are there tools that will help me debug a complex assertion?  I’ve tried
using trace, but it doesn’t seem to print out messages when it’s inside an
‘every’ or a ‘some’.   I’ve attached the example I’m trying to debug.  The
assertion in line 26 of the schema should reject the <transition> in line 7
of sample.scxml, but it doesn’t (so validation succeeds).  I can’t tell if
there’s a logical error in my schema, or if I’m not using some element
correctly.  Can someone give me some hints on how to debug the assertion’s
application?

Thanks in advance,
Jim Barnett[attachment "sample.scxml" deleted by Mark R Maxey/US/Raytheon]
[attachment "test_schema.xsd" deleted by Mark R Maxey/US/Raytheon]
----------------------------------------------

debugging tools?

Jim Barnett — 2013-05-09T14:12:46

Are there tools that will help me debug a complex assertion?  I've tried using trace, but it doesn't seem to print out messages when it's inside an 'every' or a 'some'.   I've attached the example I'm trying to debug.  The assertion in line 26 of the schema should reject the <transition> in line 7 of sample.scxml, but it doesn't (so validation succeeds).  I can't tell if there's a logical error in my schema, or if I'm not using some element correctly.  Can someone give me some hints on how to debug the assertion's application?

Thanks in advance,
Jim Barnett
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe< at >xerces.apache.org
For additional commands, e-mail: j-users-help< at >xerces.apache.org

Re: validating a XML file using XSD 1.1 with Xerces-J

Roberto Marabini — 2013-04-22T21:35:56

Dear Mukulg,

  I followed your suggestion and it worked ;-)

     Thanks

       Roberto

On Mon, Apr 22, 2013 at 2:39 PM, Mukul Gandhi <mukulg< at >apache.org> wrote:

Re: validating a XML file using XSD 1.1 with Xerces-J

Mukul Gandhi — 2013-04-22T12:39:18

your XSD document specifies the concerned element declarations as follows,

<xsd:element name="defocusU" type="defocusType"  maxOccurs="1" minOccurs="0"/>
<xsd:element name="defocusV" type="defocusType" maxOccurs="1" minOccurs="0"/>

which means that these elements are optional.

Within your XML instance document, only the first <particle> element
has the above element instances. Your assertion, <xsd:assert
test="defocusU ge defocusV" /> succeeds on the <particle> which has
the elements defocusU and defocusV but fails on the other <particle>
elements. I think, the correct way to write your assertion would be,

<xsd:assert test="if (defocusU and defocusV) then (defocusU ge
defocusV) else true()" />

Which will take care of the optional nature of these elements. Since
the complexType "defocusType" in your schema has simpleContent,
therefore "ge" operator would work fine as you're expecting.

On Mon, Apr 22, 2013 at 5:52 AM, Roberto Marabini <roberto< at >cnb.csic.es> wrote:

Re: problems using tokenize()

Mukul Gandhi — 2013-04-22T12:15:46

Its my pleasure to be of help.

On Mon, Apr 22, 2013 at 2:49 AM, Jim Barnett <Jim.Barnett< at >genesyslab.com> wrote:

validating a XML file using XSD 1.1 with Xerces-J

Roberto Marabini — 2013-04-22T00:22:32

Hi,

    I am trying to write a XSD 1.1 schema that uses  XSD 1.1
assertions. I am able to repeat the examples described in the URL:
http://mukulgandhi.blogspot.com.es/2009/11/xsd-11-some-xsd-11-samples-running-with.html
so I guess my xerces-j installation is OK.

   When I tried to include an assert in my schema (I reproduce part of
it in the email and attach the full file) I got the error message:

[Error] kk.emx:33:14: cvc-assertion.3.13.4.1: Assertion evaluation
('defocusU ge defocusV') for element 'particle' with type '#anonymous'
did not succeed.

but defocusU is indeed greater than defocusV

Note that the commented lines

<!-- <xsd:assert test="t34 le 3" />-->
<!-- <xsd:assert test="< at >index le 3" />-->

work properly when uncommented

but

        <xsd:assert test="defocusU ge defocusV" />

does not. I guess the problem is that defocusU and defocusV are complextypes

any help will be welcomed

    thanks

               Roberto
=================

Schema

<?xml version="1.1" encoding="UTF-8"?>
<xsd:sche

RE: problems using tokenize()

Jim Barnett — 2013-04-21T21:19:39

Mukul,
Yes, you are right.  Count() works as you say.

Thank you for your help.


-          Jim

From: Mukul Gandhi [mailto:mukulg< at >apache.org]
Sent: Friday, April 19, 2013 12:30 AM
To: j-users< at >xerces.apache.org
Subject: Re: problems using tokenize()

Hi Jim,
 With a boolean() function around 'tokenize' call, an "effective boolean value" of xs:string* result of 'tokenize' will be returned. But this would result in an error as per XPath 2.0 spec, for your example. I imagine, an 'exists' or 'count' function around tokenize() would let you achieve the same purpose as matches().


Sent from a mobile device.

On Thursday, April 18, 2013, Jim Barnett <Jim.Barnett< at >genesyslab.com<mailto:Jim.Barnett< at >genesyslab.com>> wrote:

--
Regards,
Mukul Gandhi

Re: problems using tokenize()

Mukul Gandhi — 2013-04-19T04:30:05

Hi Jim,
 With a boolean() function around 'tokenize' call, an "effective boolean
value" of xs:string* result of 'tokenize' will be returned. But this would
result in an error as per XPath 2.0 spec, for your example. I imagine, an
'exists' or 'count' function around tokenize() would let you achieve the
same purpose as matches().


Sent from a mobile device.

On Thursday, April 18, 2013, Jim Barnett <Jim.Barnett< at >genesyslab.com> wrote:
As before, I have an element with an attribute < at >target with type idrefs.  I
want to split the value into the individual idrefs (I will run more
complicated tests on them, but for the moment I’m just trying to get access
to them).  In the attached document and schema, I have two assertions.  The
first, using matches() succeeds, but the second, using tokenize(), fails:
xpathDefaultNamespace="##targetNamespace"/>
xpathDefaultNamespace="##targetNamespace"/>

problems using tokenize()

Jim Barnett — 2013-04-18T15:30:04

I'm having trouble getting tokenize() to behave the way I expect it to.  As before, I have an element with an attribute < at >target with type idrefs.  I want to split the value into the individual idrefs (I will run more complicated tests on them, but for the moment I'm just trying to get access to them).  In the attached document and schema, I have two assertions.  The first, using matches() succeeds, but the second, using tokenize(), fails:

<xsd:assert test="matches(string(< at >target), '\S+(\s+\S+)+')" xpathDefaultNamespace="##targetNamespace"/>
<xsd:assert test="boolean(tokenize(string(< at >target), '\s+'))"  xpathDefaultNamespace="##targetNamespace"/>

What am I doing wrong?

Thanks,
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe< at >xerces.apache.org
For additional commands, e-mail: j-users-help< at >xerces.apache.org

Re: regular expression matching in

Dawid Chodura — 2013-04-17T17:44:27

I have no easy way to test it, but I think your expression could be simplified, ie.

test="if (matches(string(< at >target), '.*')) then true() else false()"

seems to be the same as

test="matches(string(< at >target), '.*'))"

I've checked the following URL:

http://www.w3.org/TR/xquery-operators/#func-matches

and it seems that "matches" returns xs:boolean:

fn:matches($input as xs:string?, $pattern as xs:string) as xs:boolean
Summary: The function returns true if $input matches the regular expression supplied as $pattern as influenced by the value of $flags, if present; otherwise, it returns false.

Best regards,
Dawid


W dniu 17.04.2013 19:28, Jim Barnett pisze:

RE: regular expression matching in

Jim Barnett — 2013-04-17T17:28:49

Mukul,
  Yes, that fixed it.  Thank you for your prompt reply.

- Jim

-----Original Message-----
From: Mukul Gandhi [mailto:mukulg< at >apache.org] 
Sent: Wednesday, April 17, 2013 12:26 PM
To: j-users< at >xerces.apache.org
Subject: Re: regular expression matching in <assert>

Hi Jim,
    Thanks for sending across the schema and XML instance documents. I looked at the schema document you've shared.

The following fix seems to work for your problem <assert>,

<xsd:assert test="if (matches(string(< at >target), '.*')) then true() else false()"  xpathDefaultNamespace="##targetNamespace"/>

i.e, we use a string() function around attribute node < at >target. The 'target' attribute within your schema has type annotation of xsd:IDREFS, therefore we seem to need this workaround.

On Wed, Apr 17, 2013 at 9:06 PM, Jim Barnett <Jim.Barnett< at >genesyslab.com> wrote:

--
Regards,
Mukul Gandhi

---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe< at >xerces.apache.org
For additional

Re: regular expression matching in

Mukul Gandhi — 2013-04-17T16:26:00

Hi Jim,
    Thanks for sending across the schema and XML instance documents. I
looked at the schema document you've shared.

The following fix seems to work for your problem <assert>,

<xsd:assert test="if (matches(string(< at >target), '.*')) then true() else
false()"  xpathDefaultNamespace="##targetNamespace"/>

i.e, we use a string() function around attribute node < at >target. The
'target' attribute within your schema has type annotation of
xsd:IDREFS, therefore we seem to need this workaround.

On Wed, Apr 17, 2013 at 9:06 PM, Jim Barnett <Jim.Barnett< at >genesyslab.com> wrote:

RE: regular expression matching in

Jim Barnett — 2013-04-17T15:36:03

Mukul,
  Thanks for your response.  I've attached a sample schema and test file (the schema is edited down from a much larger document, so it's structure may not make much sense.)   The problem is in the <assert> in line 74 of the schema.  (The simpler <assert> in line 73 works properly.)  

I suspect that you may be right about there being a namespace problem, because the <assert> in line 74 fails even if I wrap not() around it.  So both

<xsd:assert test="if (matches(< at >target, '.*')) then true() else false()"  xpathDefaultNamespace="##targetNamespace"/>
And
<xsd:assert test="if not((matches(< at >target, '.*'))) then true() else false()"  xpathDefaultNamespace="##targetNamespace"/>

both fail, which makes it look like the processor is not finding the matches() function.  

The 'xpathDefaultNamespace="##targetNamespace"' attribute is something I stumbled across when trying to get some other assertions to work, but I admit that I don't really understand what effects it may be having.  

Thank you for your help.

Re: regular expression matching in

Mukul Gandhi — 2013-04-17T14:54:53

Hi Jim,
    Our XSD 1.1 <assert> implementation can use XPath 2.0 matches()
and tokenize() functions fine. Our <assert> XPath 2.0 processor passes
all W3C XPath 2.0 tests.

I've checked your example with current Xerces SVN, and I don't find
any bug wrt your example. I can see, that you use the
xpathDefaultNamespace attribute on <assert> which may be causing
issues.

If you can post a complete XSD schema document along with an XML
instance document, we could debug better.

On Wed, Apr 17, 2013 at 12:12 AM, Jim Barnett
<Jim.Barnett< at >genesyslab.com> wrote:

regular expression matching in

Jim Barnett — 2013-04-16T18:42:07

Are matches() and tokenize() supported inside <assert> when doing schema validation?  I am applying an assertion to an element with a 'target' attribute whose value is "s1 s2", yet the following assertion is failing:

<xsd:assert test="if (matches(< at >target, '.*')) then true()  else false()"  xpathDefaultNamespace="##targetNamespace"/>

Any guidance would be appreciated.

Thanks,
Jim

Validate XML by XSD failes with jDOM and Xerces 2.10.0

Ronny — 2013-04-05T14:11:39

Hi list,

I've got a problem validating a xml by a xsd.

A short preview about the xsd:

<complexType name="MyType2">
 <attribute name="MyAttribute" type="string" use="required" />
</complexType>

<complexType name="MyType1 ... />

<element name="MyRoot">
 <complexType>
  <choice>
   <element name="MyType1" ... />
   <element name="MyType2" type="MyType2" minOccurs="1" maxOccurs="1" />
  </choice>
 </complexType>
</element>


Ok, my XML file looks like this:

<MyRoot xmlns="..." ...>
 <MyType2 MyAttribute="something">
  ...
 </MyType2>
</MyRoot>


Now I try to validate this with jDOM by using xerces. Then I got the
following error:
 - Error on line 6: cvc-complex-type.3.2.2: Attribute "MyAttribute" must
not occur in element "MyType2".


I validated the same xml with the same xsd with oXygen (which also uses
xerces) and with some online validators. All told me that the xml is valid.

So my question is, why does the JAVA implementation gives tells me that
the xml is not valid.

I'm grateful for some hints.

Th

Re: Validate XML by XSD failes with jDOM and Xerces 2.10.0

Mukul Gandhi — 2013-04-06T08:48:55


That is fine and then you should provide a Xerces jar within your
classpath, which you seem to have already done.


I'm really not sure, if substituting a latest Xerces jar within your
JDOM runtime classpath, may be sufficient to make available
functionality of this Xerces jar to your JDOM runtime. Your JDOM
runtime may be using Xerces in some other way.


As I wrote earlier, simply placing a new Xerces jar within your JDOM
classpath may not be a sufficient condition to make available
functionality of this Xerces jar to your JDOM application.

Therefore, my guess currently wrt this issue are,
1) Either JDOM doesn't support using new Xerces jars, in this way.
2) Or you may need to do a JDOM specific configuration, to be able to
use new Xerces jars

You may have to ask support for this query, to JDOM forum or if
someone here can provide a better explanation perhaps.


Sorry if this is not helpful.

Re: Validate XML by XSD failes with jDOM and Xerces 2.10.0

Ronny — 2013-04-06T09:50:17

Sorry. Of course I configured jdom to use the external xerces. Without 
putting the xerces jar into the class path I get errors.

Vom Handy gesendet.



Am 6. April 2013 10:48:55 schrieb Mukul Gandhi <mukulg< at >apache.org>:

Re: Validate XML by XSD failes with jDOM and Xerces 2.10.0

Mukul Gandhi — 2013-04-06T03:29:40

Does JDOM has a native Xerces-J XSD integration? If its kind of that,
then the XSD processor active within your JDOM runtime may have a
validator bug. If that is so, you may need to report this problem to
JDOM forum.

As far as I know, Xerces-J doesn't provide explicit JDOM integration.
Another approach you can try is if you're constrained to use a JDOM
representation of your input XML for XSD validation is to following
steps like below,
1) Serialize the JDOM tree into an XML document (like a file, string etc).
2) Then use result of step 1) and your XSD document, to do schema
validation with Xerces-J. This would also allow you to integrate an
externally available (which may have a better XSD compliance, that the
validator currently active in your JDOM implementation) Xerces-J
library, with your JDOM input.

Having written all of this, I really haven't verified the internals of
JDOM. Please correct me, if I'm wrong.

On Fri, Apr 5, 2013 at 7:41 PM, Ronny <Ronny< at >bigfunfitness.de> wrote:


--
Regards,
Mukul Gan