vtd-xml-users — This mailing list is for users or people interested in VTD-XML

Re: [Vtd-xml-users] xerces discussion on VTD

[Jimmy Z. <cra...@co...>]

XSD is definitely going to come out in the next several releases...
and the challenge ahead is to make it not just usable, but persistent
and high performance... and the possibility of ASIC implemenation
is going to be explored

for version 2.0 we will introduce VTD+XML feature... and any suggestion
on the core API implementation is very welcome...


----- Original Message ----- 
From: "Paul Tomsic" <pt...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Wednesday, January 17, 2007 10:50 AM
Subject: Re: xerces discussion on VTD


>i agree on the getting out of the cave, per se.
> python does a great job of handling XML via it's etree implementation,
> and there's really not much competition for it.  since java's got a
> different xml implementation around every corner, then it's easy to
> dismiss something other than one's that ppl recognize (SAX/DOM/etc)
>
> i'd love to see VTD support XSD's, specifically schema validation, and
> the ability to determine backward compatibility within an XSD.  I've
> yet to find something that can determine if an XSD is backward
> compatible or not.
>
>
>
> On 1/17/07, Jimmy Zhang <cra...@co...> wrote:
>> Thanks. It would take sometime to take VTD seriously...
>> Given that DOM and SAX are so bad for so long, people
>> have literally got used to them... and sometime had a tough
>> time getting out of the "cave."
>> ----- Original Message -----
>> From: "Paul Tomsic" <pt...@gm...>
>> To: <vtd...@li...>; <cra...@co...>
>> Sent: Wednesday, January 17, 2007 6:17 AM
>> Subject: xerces discussion on VTD
>>
>>
>> > interesting thread, thought you might want to comment if you've not 
>> > seen
>> > it:
>> >
>> > http://www.nabble.com/VTD-XML-thoughts--tf2816326.html
>> >
>>
>>
>>
> 

Re: [Vtd-xml-users] xerces discussion on VTD

[Jimmy Z. <cra...@co...>]

See my comments below

----- Original Message ----- 
From: "Tatu Saloranta" <cow...@ya...>
To: "Jimmy Zhang" <cra...@co...>; "Paul Tomsic" <pt...@gm...>; 
<vtd...@li...>
Sent: Wednesday, January 17, 2007 10:48 AM
Subject: Re: [Vtd-xml-users] xerces discussion on VTD


> --- Jimmy Zhang <cra...@co...> wrote:
>
>> Thanks. It would take sometime to take VTD
>> seriously...
>> Given that DOM and SAX are so bad for so long,
>> people
>> have literally got used to them... and sometime had
>> a tough
>> time getting out of the "cave."
>
> It is true, however, that VTD-XML as well as any other
> tools has its optimal use cases, and limits.
> I think it is useful to be clear about both benefits
> (compact representation, efficient just-in-time
> extraction if only parts of content are needed, fast
> serialization likewise if modifications are small) and
> limitations.
>
> There are really 2 major limitations I think:
>
> (a) It does not (and probably will not) handle DTDs:
> validation is not the problem (it could be
> implemented), but entities are, and perhaps things
> like attribute defaulting and normalization. This may
> be problematic for document-centric approaches, but
> usually is not for data-centric (like SOAP messages
> etc)

DTD seems to have been depleted somewhat, e.g.
in SOAP, various types of industry specific vocabularies,
RDFs... XPath and XQuery doesn't even have the notion
of DTD anymore...

> (b) Namespace handling is not very complete, nor
> efficient; this because the way namespaces work is
> somewhat conflicting with the way VTD-XML does its
> processing, to obtain high speed. So I am not sure if
> it should be used for documents with namespaces.
>

The name space handling is quite efficient... most cases
I have not seen much difference at all... as to the completion
part, I have two thoughts, one is that the namespace spec
itself has issues, the second is that adding complete support
of it should not be difficult nor inefficient...

> There are still many use cases where neither above is
> a problem: but there are also cases where it is.
> Clearly understanding limitations and benefits, and
> choosing right tools based on this is essential.
>

I don't know why some kept thinking VTD is compressed
DOM...does it look like compressed DOM to you?


> -+ Tatu +-
>
>
>
>
>
> ____________________________________________________________________________________
> Have a burning question?
> Go to www.Answers.yahoo.com and get answers from real people who know.
> 

Re: [Vtd-xml-users] xerces discussion on VTD

[Tatu S. <cow...@ya...>]

--- Paul Tomsic <pt...@gm...> wrote:

...
> i'd love to see VTD support XSD's, specifically
> schema validation, and
> the ability to determine backward compatibility

I don't think it absolutely must be implemented by VTD
itself however. But it should be possible to integrate
something like Multi-Schema Validator, to validate VTD
trees (against W3C Schema, or Relax NG).

> within an XSD.  I've
> yet to find something that can determine if an XSD
> is backward
> compatible or not.

Likewise, this sounds like task for a schema
processing tool, and writing one is probably even more
work than writing efficient parsers. I think
separation of concerns is good.

-+ Tatu +-



 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

Re: [Vtd-xml-users] xerces discussion on VTD

[Paul T. <pt...@gm...>]

i agree on the getting out of the cave, per se.
python does a great job of handling XML via it's etree implementation,
and there's really not much competition for it.  since java's got a
different xml implementation around every corner, then it's easy to
dismiss something other than one's that ppl recognize (SAX/DOM/etc)

i'd love to see VTD support XSD's, specifically schema validation, and
the ability to determine backward compatibility within an XSD.  I've
yet to find something that can determine if an XSD is backward
compatible or not.



On 1/17/07, Jimmy Zhang <cra...@co...> wrote:
> Thanks. It would take sometime to take VTD seriously...
> Given that DOM and SAX are so bad for so long, people
> have literally got used to them... and sometime had a tough
> time getting out of the "cave."
> ----- Original Message -----
> From: "Paul Tomsic" <pt...@gm...>
> To: <vtd...@li...>; <cra...@co...>
> Sent: Wednesday, January 17, 2007 6:17 AM
> Subject: xerces discussion on VTD
>
>
> > interesting thread, thought you might want to comment if you've not seen
> > it:
> >
> > http://www.nabble.com/VTD-XML-thoughts--tf2816326.html
> >
>
>
>

Re: [Vtd-xml-users] xerces discussion on VTD

[Tatu S. <cow...@ya...>]

--- Jimmy Zhang <cra...@co...> wrote:

> Thanks. It would take sometime to take VTD
> seriously...
> Given that DOM and SAX are so bad for so long,
> people
> have literally got used to them... and sometime had
> a tough
> time getting out of the "cave."

It is true, however, that VTD-XML as well as any other
tools has its optimal use cases, and limits.
I think it is useful to be clear about both benefits
(compact representation, efficient just-in-time
extraction if only parts of content are needed, fast
serialization likewise if modifications are small) and
limitations.

There are really 2 major limitations I think:

(a) It does not (and probably will not) handle DTDs:
validation is not the problem (it could be
implemented), but entities are, and perhaps things
like attribute defaulting and normalization. This may
be problematic for document-centric approaches, but
usually is not for data-centric (like SOAP messages
etc)
(b) Namespace handling is not very complete, nor
efficient; this because the way namespaces work is
somewhat conflicting with the way VTD-XML does its
processing, to obtain high speed. So I am not sure if
it should be used for documents with namespaces.

There are still many use cases where neither above is
a problem: but there are also cases where it is.
Clearly understanding limitations and benefits, and
choosing right tools based on this is essential.

-+ Tatu +-




 
____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

Re: [Vtd-xml-users] xerces discussion on VTD

[Jimmy Z. <cra...@co...>]

Thanks. It would take sometime to take VTD seriously...
Given that DOM and SAX are so bad for so long, people
have literally got used to them... and sometime had a tough
time getting out of the "cave."
----- Original Message ----- 
From: "Paul Tomsic" <pt...@gm...>
To: <vtd...@li...>; <cra...@co...>
Sent: Wednesday, January 17, 2007 6:17 AM
Subject: xerces discussion on VTD


> interesting thread, thought you might want to comment if you've not seen 
> it:
>
> http://www.nabble.com/VTD-XML-thoughts--tf2816326.html
> 

[Vtd-xml-users] xerces discussion on VTD

[Paul T. <pt...@gm...>]

interesting thread, thought you might want to comment if you've not seen it:

http://www.nabble.com/VTD-XML-thoughts--tf2816326.html

Re: [Vtd-xml-users] Converting data based upon tag attribute names?

[Tatu S. <cow...@ya...>]

What you describe is called data binding. VTD-XML is
an xml parser + tree model, and does not handle data
binding (xml <-> objects).
However, one could build a data binding package on top
of it (either for specific use case, hand writing, or
a generic system, like JAXB, Castor, XMLBeans, JibX,
Betwixt etc).

-+ Tatu +-

--- ma...@sh... wrote:

> I'm new to VTD-XML, and I was wondering if the
> following wml could be  
> converted to  java objects using this technology:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <response>
>    <responseHeader>
>      <status>0</status><QTime>1</QTime>
>    </responseHeader>
> 
>    <result numFound="2" start="0">
>     <doc>
>      <str name="id">MA147LL/A</str>
>      <str name="name">Apple 60 GB iPod Black</str>
>     </doc>
>     <doc>
>      <str name="id">EN7800GTX/2DHTV/256M</str>
>      <str name="name">ASUS Extreme N7800GTX</str>
>     </doc>
>    </result>
> </response>
> 
> Important are the <str name=" tags, as you see I
> need to map them to  
> object fields based upon their attribute name, can
> this be done?
> 
> Grtz
> 
> 
>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys - and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
>
https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> 



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Re: [Vtd-xml-users] Converting data based upon tag attribute names?

[Jimmy Z. <cra...@co...>]

After parsing, you get a graph similar to a DOM tree that you can
navigate using a cursor...
if by java objects you are referring to JAXB style of binding, then
there got to be schema available...
----- Original Message ----- 
From: <ma...@sh...>
To: <vtd...@li...>
Sent: Tuesday, January 16, 2007 6:13 AM
Subject: [Vtd-xml-users] Converting data based upon tag attribute names?


> I'm new to VTD-XML, and I was wondering if the following wml could be
> converted to  java objects using this technology:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <response>
>   <responseHeader>
>     <status>0</status><QTime>1</QTime>
>   </responseHeader>
>
>   <result numFound="2" start="0">
>    <doc>
>     <str name="id">MA147LL/A</str>
>     <str name="name">Apple 60 GB iPod Black</str>
>    </doc>
>    <doc>
>     <str name="id">EN7800GTX/2DHTV/256M</str>
>     <str name="name">ASUS Extreme N7800GTX</str>
>    </doc>
>   </result>
> </response>
>
> Important are the <str name=" tags, as you see I need to map them to
> object fields based upon their attribute name, can this be done?
>
> Grtz
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> 

Re: [Vtd-xml-users] Fw: patch for 1.4 jdk compat...

[Paul T. <pt...@gm...>]

yes, it works.  I've attached a simple test case to verify that is true.
uncommenting the line w/ the offset incrementor seemed to do the trick.


On 1/13/07, Jimmy Zhang <cra...@co...> wrote:
>
>  can you also verify the "getCharResolved" bug has been fixed?
> The fix of 1.4 compatibility will be in version 2.0..
>  Thanks!
> >> ----- Original Message -----
> >> From: "Paul Tomsic" <pt...@gm...>
> >> To: "Jimmy Zhang" <cra...@co...>
> >> Cc: <vtd...@li...>
> >> Sent: Saturday, January 13, 2007 8:15 AM
> >> Subject: Re: [Vtd-xml-users] patch for 1.4 jdk compat...
> >>
> >>
> >>> ah, cool, so my null check's not necessary, but at least that one
> >>> change (from contains to indexOf) will make it 1.4 compat.
> >>>
> >>> thanks
> >>>
> >>>
> >>> On 1/12/07, Jimmy Zhang <cra...@co...> wrote:
> >>>> Yes, you are correct on s1 being a null pointer, and during the design
> >>>> I
> >>>> have thought
> >>>> about this case... but it turned out that if the XPath is compiled
> >>>> correctly, a string will
> >>>> never be null, in xpath 1.0 spec, in the worst case, the string returns
> >>>> a
> >>>> zero length string
> >>>> "". So null actually never occurs...
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Paul Tomsic" <pt...@gm...>
> >>>> To: "Jimmy Zhang" <cra...@co...>
> >>>> Cc: <vtd...@li...>
> >>>> Sent: Thursday, January 11, 2007 11:34 AM
> >>>> Subject: Re: [Vtd-xml-users] patch for 1.4 jdk compat...
> >>>>
> >>>>
> >>>> > sure.
> >>>> > it's really just a replacement of the String.contains() method, to a
> >>>> > indexOf()
> >>>> >
> >>>> > also i do null checking, since that method itself could throw a
> >>>> > nullptr if "s1" is null.
> >>>> > not sure if that's the intention or not.
> >>>> >
> >>>> > 265c265
> >>>> > <     return s1.contains(s2);
> >>>> > ---
> >>>> >>         return s1 != null && s2 != null && s1.indexOf(s2) != -1;
> >>>> >
> >>>> >
> >>>> > the top one is the way it exists currently, and the bottom one is my
> >>>> > change
> >>>> > (FuncExpr.java:265)
> >>>> >
> >>>> >
> >>>> > On 1/11/07, Jimmy Zhang <cra...@co...> wrote:
> >>>> >> I am running windows so is there a full text version you can
> >>>> >> email to me directly? I kinda have trouble open the diff file...
> >>>> >>
> >>>> >> ----- Original Message -----
> >>>> >> From: "Paul Tomsic" <pt...@gm...>
> >>>> >> To: <vtd...@li...>
> >>>> >> Sent: Thursday, January 11, 2007 9:42 AM
> >>>> >> Subject: [Vtd-xml-users] patch for 1.4 jdk compat...
> >>>> >>
> >>>> >>
> >>>> >> > hi, i noticed that there's only one line of code in the codebase
> >>>> >> > (at
> >>>> >> > least as of today's cvs) that makes vtd not backward compat w/
> >>>> >> > 1.4.
> >>>> >> >
> >>>> >> > i've attached a patch for FuncExpr.java.  hopefully this is
> >>>> >> > helpful
> >>>> >> >
> >>>> >>
> >>>> >>
> >>>> >> --------------------------------------------------------------------------------
> >>>> >>
> >>>> >>
> >>>> >> > -------------------------------------------------------------------------
> >>>> >> > Take Surveys. Earn Cash. Influence the Future of IT
> >>>> >> > Join SourceForge.net's Techsay panel and you'll get the chance to
> >>>> >> > share
> >>>> >> > your
> >>>> >> > opinions on IT & business topics through brief surveys - and earn
> >>>> >> > cash
> >>>> >> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>>> >>
> >>>> >>
> >>>> >> --------------------------------------------------------------------------------
> >>>> >>
> >>>> >>
> >>>> >> > _______________________________________________
> >>>> >> > Vtd-xml-users mailing list
> >>>> >> > Vtd...@li...
> >>>> >> > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> >>>> >> >
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
>

[Vtd-xml-users] Converting data based upon tag attribute names?

[<ma...@sh...>]

I'm new to VTD-XML, and I was wondering if the following wml could be  
converted to  java objects using this technology:

<?xml version="1.0" encoding="UTF-8"?>
<response>
   <responseHeader>
     <status>0</status><QTime>1</QTime>
   </responseHeader>

   <result numFound="2" start="0">
    <doc>
     <str name="id">MA147LL/A</str>
     <str name="name">Apple 60 GB iPod Black</str>
    </doc>
    <doc>
     <str name="id">EN7800GTX/2DHTV/256M</str>
     <str name="name">ASUS Extreme N7800GTX</str>
    </doc>
   </result>
</response>

Important are the <str name=" tags, as you see I need to map them to  
object fields based upon their attribute name, can this be done?

Grtz

[Vtd-xml-users] Fw: patch for 1.4 jdk compat...

[Jimmy Z. <cra...@co...>]

 can you also verify the "getCharResolved" bug has been fixed?
The fix of 1.4 compatibility will be in version 2.0..
 Thanks!
>> ----- Original Message ----- 
>> From: "Paul Tomsic" <pt...@gm...>
>> To: "Jimmy Zhang" <cra...@co...>
>> Cc: <vtd...@li...>
>> Sent: Saturday, January 13, 2007 8:15 AM
>> Subject: Re: [Vtd-xml-users] patch for 1.4 jdk compat...
>>
>>
>>> ah, cool, so my null check's not necessary, but at least that one
>>> change (from contains to indexOf) will make it 1.4 compat.
>>>
>>> thanks
>>>
>>>
>>> On 1/12/07, Jimmy Zhang <cra...@co...> wrote:
>>>> Yes, you are correct on s1 being a null pointer, and during the design 
>>>> I
>>>> have thought
>>>> about this case... but it turned out that if the XPath is compiled
>>>> correctly, a string will
>>>> never be null, in xpath 1.0 spec, in the worst case, the string returns 
>>>> a
>>>> zero length string
>>>> "". So null actually never occurs...
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Paul Tomsic" <pt...@gm...>
>>>> To: "Jimmy Zhang" <cra...@co...>
>>>> Cc: <vtd...@li...>
>>>> Sent: Thursday, January 11, 2007 11:34 AM
>>>> Subject: Re: [Vtd-xml-users] patch for 1.4 jdk compat...
>>>>
>>>>
>>>> > sure.
>>>> > it's really just a replacement of the String.contains() method, to a
>>>> > indexOf()
>>>> >
>>>> > also i do null checking, since that method itself could throw a
>>>> > nullptr if "s1" is null.
>>>> > not sure if that's the intention or not.
>>>> >
>>>> > 265c265
>>>> > <     return s1.contains(s2);
>>>> > ---
>>>> >>         return s1 != null && s2 != null && s1.indexOf(s2) != -1;
>>>> >
>>>> >
>>>> > the top one is the way it exists currently, and the bottom one is my
>>>> > change
>>>> > (FuncExpr.java:265)
>>>> >
>>>> >
>>>> > On 1/11/07, Jimmy Zhang <cra...@co...> wrote:
>>>> >> I am running windows so is there a full text version you can
>>>> >> email to me directly? I kinda have trouble open the diff file...
>>>> >>
>>>> >> ----- Original Message -----
>>>> >> From: "Paul Tomsic" <pt...@gm...>
>>>> >> To: <vtd...@li...>
>>>> >> Sent: Thursday, January 11, 2007 9:42 AM
>>>> >> Subject: [Vtd-xml-users] patch for 1.4 jdk compat...
>>>> >>
>>>> >>
>>>> >> > hi, i noticed that there's only one line of code in the codebase 
>>>> >> > (at
>>>> >> > least as of today's cvs) that makes vtd not backward compat w/ 
>>>> >> > 1.4.
>>>> >> >
>>>> >> > i've attached a patch for FuncExpr.java.  hopefully this is 
>>>> >> > helpful
>>>> >> >
>>>> >>
>>>> >>
>>>> >> --------------------------------------------------------------------------------
>>>> >>
>>>> >>
>>>> >> > -------------------------------------------------------------------------
>>>> >> > Take Surveys. Earn Cash. Influence the Future of IT
>>>> >> > Join SourceForge.net's Techsay panel and you'll get the chance to 
>>>> >> > share
>>>> >> > your
>>>> >> > opinions on IT & business topics through brief surveys - and earn 
>>>> >> > cash
>>>> >> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>>> >>
>>>> >>
>>>> >> --------------------------------------------------------------------------------
>>>> >>
>>>> >>
>>>> >> > _______________________________________________
>>>> >> > Vtd-xml-users mailing list
>>>> >> > Vtd...@li...
>>>> >> > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>
>>
> 

Re: [Vtd-xml-users] patch for 1.4 jdk compat...

[Paul T. <pt...@gm...>]

ah, cool, so my null check's not necessary, but at least that one
change (from contains to indexOf) will make it 1.4 compat.

thanks


On 1/12/07, Jimmy Zhang <cra...@co...> wrote:
> Yes, you are correct on s1 being a null pointer, and during the design I
> have thought
> about this case... but it turned out that if the XPath is compiled
> correctly, a string will
> never be null, in xpath 1.0 spec, in the worst case, the string returns a
> zero length string
> "". So null actually never occurs...
>
>
> ----- Original Message -----
> From: "Paul Tomsic" <pt...@gm...>
> To: "Jimmy Zhang" <cra...@co...>
> Cc: <vtd...@li...>
> Sent: Thursday, January 11, 2007 11:34 AM
> Subject: Re: [Vtd-xml-users] patch for 1.4 jdk compat...
>
>
> > sure.
> > it's really just a replacement of the String.contains() method, to a
> > indexOf()
> >
> > also i do null checking, since that method itself could throw a
> > nullptr if "s1" is null.
> > not sure if that's the intention or not.
> >
> > 265c265
> > <     return s1.contains(s2);
> > ---
> >>         return s1 != null && s2 != null && s1.indexOf(s2) != -1;
> >
> >
> > the top one is the way it exists currently, and the bottom one is my
> > change
> > (FuncExpr.java:265)
> >
> >
> > On 1/11/07, Jimmy Zhang <cra...@co...> wrote:
> >> I am running windows so is there a full text version you can
> >> email to me directly? I kinda have trouble open the diff file...
> >>
> >> ----- Original Message -----
> >> From: "Paul Tomsic" <pt...@gm...>
> >> To: <vtd...@li...>
> >> Sent: Thursday, January 11, 2007 9:42 AM
> >> Subject: [Vtd-xml-users] patch for 1.4 jdk compat...
> >>
> >>
> >> > hi, i noticed that there's only one line of code in the codebase (at
> >> > least as of today's cvs) that makes vtd not backward compat w/ 1.4.
> >> >
> >> > i've attached a patch for FuncExpr.java.  hopefully this is helpful
> >> >
> >>
> >>
> >> --------------------------------------------------------------------------------
> >>
> >>
> >> > -------------------------------------------------------------------------
> >> > Take Surveys. Earn Cash. Influence the Future of IT
> >> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> >> > your
> >> > opinions on IT & business topics through brief surveys - and earn cash
> >> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>
> >>
> >> --------------------------------------------------------------------------------
> >>
> >>
> >> > _______________________________________________
> >> > Vtd-xml-users mailing list
> >> > Vtd...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> >> >
> >>
> >>
> >>
> >
>
>
>

Re: [Vtd-xml-users] patch for 1.4 jdk compat...

[Jimmy Z. <cra...@co...>]

Yes, you are correct on s1 being a null pointer, and during the design I 
have thought
about this case... but it turned out that if the XPath is compiled 
correctly, a string will
never be null, in xpath 1.0 spec, in the worst case, the string returns a 
zero length string
"". So null actually never occurs...


----- Original Message ----- 
From: "Paul Tomsic" <pt...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Thursday, January 11, 2007 11:34 AM
Subject: Re: [Vtd-xml-users] patch for 1.4 jdk compat...


> sure.
> it's really just a replacement of the String.contains() method, to a 
> indexOf()
>
> also i do null checking, since that method itself could throw a
> nullptr if "s1" is null.
> not sure if that's the intention or not.
>
> 265c265
> <     return s1.contains(s2);
> ---
>>         return s1 != null && s2 != null && s1.indexOf(s2) != -1;
>
>
> the top one is the way it exists currently, and the bottom one is my 
> change
> (FuncExpr.java:265)
>
>
> On 1/11/07, Jimmy Zhang <cra...@co...> wrote:
>> I am running windows so is there a full text version you can
>> email to me directly? I kinda have trouble open the diff file...
>>
>> ----- Original Message -----
>> From: "Paul Tomsic" <pt...@gm...>
>> To: <vtd...@li...>
>> Sent: Thursday, January 11, 2007 9:42 AM
>> Subject: [Vtd-xml-users] patch for 1.4 jdk compat...
>>
>>
>> > hi, i noticed that there's only one line of code in the codebase (at
>> > least as of today's cvs) that makes vtd not backward compat w/ 1.4.
>> >
>> > i've attached a patch for FuncExpr.java.  hopefully this is helpful
>> >
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>> > -------------------------------------------------------------------------
>> > Take Surveys. Earn Cash. Influence the Future of IT
>> > Join SourceForge.net's Techsay panel and you'll get the chance to share
>> > your
>> > opinions on IT & business topics through brief surveys - and earn cash
>> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>> > _______________________________________________
>> > Vtd-xml-users mailing list
>> > Vtd...@li...
>> > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
>> >
>>
>>
>>
> 

Re: [Vtd-xml-users] patch for 1.4 jdk compat...

[Paul T. <pt...@gm...>]

sure.
it's really just a replacement of the String.contains() method, to a indexOf()

also i do null checking, since that method itself could throw a
nullptr if "s1" is null.
not sure if that's the intention or not.

265c265
< 	    return s1.contains(s2);
---
>         return s1 != null && s2 != null && s1.indexOf(s2) != -1;


the top one is the way it exists currently, and the bottom one is my change
(FuncExpr.java:265)


On 1/11/07, Jimmy Zhang <cra...@co...> wrote:
> I am running windows so is there a full text version you can
> email to me directly? I kinda have trouble open the diff file...
>
> ----- Original Message -----
> From: "Paul Tomsic" <pt...@gm...>
> To: <vtd...@li...>
> Sent: Thursday, January 11, 2007 9:42 AM
> Subject: [Vtd-xml-users] patch for 1.4 jdk compat...
>
>
> > hi, i noticed that there's only one line of code in the codebase (at
> > least as of today's cvs) that makes vtd not backward compat w/ 1.4.
> >
> > i've attached a patch for FuncExpr.java.  hopefully this is helpful
> >
>
>
> --------------------------------------------------------------------------------
>
>
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
>
> --------------------------------------------------------------------------------
>
>
> > _______________________________________________
> > Vtd-xml-users mailing list
> > Vtd...@li...
> > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> >
>
>
>

Re: [Vtd-xml-users] patch for 1.4 jdk compat...

[Jimmy Z. <cra...@co...>]

I am running windows so is there a full text version you can
email to me directly? I kinda have trouble open the diff file...

----- Original Message ----- 
From: "Paul Tomsic" <pt...@gm...>
To: <vtd...@li...>
Sent: Thursday, January 11, 2007 9:42 AM
Subject: [Vtd-xml-users] patch for 1.4 jdk compat...


> hi, i noticed that there's only one line of code in the codebase (at
> least as of today's cvs) that makes vtd not backward compat w/ 1.4.
>
> i've attached a patch for FuncExpr.java.  hopefully this is helpful
>


--------------------------------------------------------------------------------


> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


--------------------------------------------------------------------------------


> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> 

[Vtd-xml-users] patch for 1.4 jdk compat...

[Paul T. <pt...@gm...>]

hi, i noticed that there's only one line of code in the codebase (at
least as of today's cvs) that makes vtd not backward compat w/ 1.4.

i've attached a patch for FuncExpr.java.  hopefully this is helpful

Re: [Vtd-xml-users] more information on aforementioned BinaryExpr bug...

[Jimmy Z. <cra...@co...>]

 This bug has been reported and may have been fixed already, just go to
the CVS of vtd-xml and download the latest version of VTDNav.java...

Jimmy
----- Original Message ----- 
From: "Paul Tomsic" <pt...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Wednesday, January 10, 2007 1:59 PM
Subject: more information on aforementioned BinaryExpr bug...


> seems it's definitely surrounding the &amp; being a value for an 
> attribute.
>
> it's entering VTDNav.getCharResolved(int) w/ a value of 413 for the 
> offset.
> hits the switch stmt @ line 632, and simply falls into the default
> which throws an exception.
>
>
> On 1/10/07, Paul Tomsic <pt...@gm...> wrote:
>> Hello, while using v.1.9 (and actually, i believe it's a bug in prior
>> versions dating back to 1.5)
>> i'm getting the stack trace below.
>>
>> I've attached a simple unit test that emulates this behaviour.
>> Within my unit test, if you substitute "FAILING_CODE" with "PASSING_CODE"
>> on line 23, the error doesn't occur.
>>
>> As near as i can tell, it's got something to do w/ the "bean" element
>> that is directly beneath a bean element that contains the "&amp;"
>> symbol, as is the case w/ the "AIR" bean"
>>
>> if the attachment doesn't make it, i can simply inline the class, let me 
>> know
>>
>> thoughts?
>>
>> --- stack trace ---
>>
>>     [junit] Testcase: 
>> testCompStringNodeSet(com.ximpleware.BinaryExprTest):
>> Caused an ERROR
>>     [junit] Undefined behavior
>>     [junit] java.lang.RuntimeException: Undefined behavior
>>     [junit]     at
>> com.ximpleware.BinaryExpr.compStringNodeSet(BinaryExpr.java:364)
>>     [junit]     at 
>> com.ximpleware.BinaryExpr.computeEQNE(BinaryExpr.java:234)
>>     [junit]     at 
>> com.ximpleware.BinaryExpr.evalBoolean(BinaryExpr.java:113)
>>     [junit]     at 
>> com.ximpleware.BinaryExpr.evalBoolean(BinaryExpr.java:111)
>>     [junit]     at com.ximpleware.xpath.Predicate.eval(Predicate.java:41)
>>     [junit]     at 
>> com.ximpleware.xpath.Step.evalPredicates(Step.java:118)
>>     [junit]     at com.ximpleware.xpath.Step.eval(Step.java:108)
>>     [junit]     at
>> com.ximpleware.LocationPathExpr.process_child(LocationPathExpr.java:291)
>>     [junit]     at
>> com.ximpleware.LocationPathExpr.evalNodeSet(LocationPathExpr.java:1556)
>>     [junit]     at 
>> com.ximpleware.UnionExpr.evalNodeSet(UnionExpr.java:111)
>>     [junit]     at com.ximpleware.AutoPilot.evalXPath(AutoPilot.java:549)
>>     [junit]     at
>> com.ximpleware.BinaryExprTest.testCompStringNodeSet(BinaryExprTest.java:28)
>>     [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
>> Method)
>>     [junit]     at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>     [junit]     at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>>
>>
> 

[Vtd-xml-users] more information on aforementioned BinaryExpr bug...

[Paul T. <pt...@gm...>]

seems it's definitely surrounding the & being a value for an attribute.

it's entering VTDNav.getCharResolved(int) w/ a value of 413 for the offset.
hits the switch stmt @ line 632, and simply falls into the default
which throws an exception.


On 1/10/07, Paul Tomsic <pt...@gm...> wrote:
> Hello, while using v.1.9 (and actually, i believe it's a bug in prior
> versions dating back to 1.5)
> i'm getting the stack trace below.
>
> I've attached a simple unit test that emulates this behaviour.
> Within my unit test, if you substitute "FAILING_CODE" with "PASSING_CODE"
> on line 23, the error doesn't occur.
>
> As near as i can tell, it's got something to do w/ the "bean" element
> that is directly beneath a bean element that contains the "&amp;"
> symbol, as is the case w/ the "AIR" bean"
>
> if the attachment doesn't make it, i can simply inline the class, let me know
>
> thoughts?
>
> --- stack trace ---
>
>     [junit] Testcase: testCompStringNodeSet(com.ximpleware.BinaryExprTest):
> Caused an ERROR
>     [junit] Undefined behavior
>     [junit] java.lang.RuntimeException: Undefined behavior
>     [junit]     at
> com.ximpleware.BinaryExpr.compStringNodeSet(BinaryExpr.java:364)
>     [junit]     at com.ximpleware.BinaryExpr.computeEQNE(BinaryExpr.java:234)
>     [junit]     at com.ximpleware.BinaryExpr.evalBoolean(BinaryExpr.java:113)
>     [junit]     at com.ximpleware.BinaryExpr.evalBoolean(BinaryExpr.java:111)
>     [junit]     at com.ximpleware.xpath.Predicate.eval(Predicate.java:41)
>     [junit]     at com.ximpleware.xpath.Step.evalPredicates(Step.java:118)
>     [junit]     at com.ximpleware.xpath.Step.eval(Step.java:108)
>     [junit]     at
> com.ximpleware.LocationPathExpr.process_child(LocationPathExpr.java:291)
>     [junit]     at
> com.ximpleware.LocationPathExpr.evalNodeSet(LocationPathExpr.java:1556)
>     [junit]     at com.ximpleware.UnionExpr.evalNodeSet(UnionExpr.java:111)
>     [junit]     at com.ximpleware.AutoPilot.evalXPath(AutoPilot.java:549)
>     [junit]     at
> com.ximpleware.BinaryExprTest.testCompStringNodeSet(BinaryExprTest.java:28)
>     [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     [junit]     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>     [junit]     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
>
>

[Vtd-xml-users] possible bug, BinaryExpr.compStringNodeSet(BinaryExpr.java:364) ...

[Paul T. <pt...@gm...>]

Hello, while using v.1.9 (and actually, i believe it's a bug in prior
versions dating back to 1.5)
i'm getting the stack trace below.

I've attached a simple unit test that emulates this behaviour.
Within my unit test, if you substitute "FAILING_CODE" with "PASSING_CODE"
on line 23, the error doesn't occur.

As near as i can tell, it's got something to do w/ the "bean" element
that is directly beneath a bean element that contains the "&"
symbol, as is the case w/ the "AIR" bean"

if the attachment doesn't make it, i can simply inline the class, let me know

thoughts?

--- stack trace ---

    [junit] Testcase: testCompStringNodeSet(com.ximpleware.BinaryExprTest):
Caused an ERROR
    [junit] Undefined behavior
    [junit] java.lang.RuntimeException: Undefined behavior
    [junit]     at
com.ximpleware.BinaryExpr.compStringNodeSet(BinaryExpr.java:364)
    [junit]     at com.ximpleware.BinaryExpr.computeEQNE(BinaryExpr.java:234)
    [junit]     at com.ximpleware.BinaryExpr.evalBoolean(BinaryExpr.java:113)
    [junit]     at com.ximpleware.BinaryExpr.evalBoolean(BinaryExpr.java:111)
    [junit]     at com.ximpleware.xpath.Predicate.eval(Predicate.java:41)
    [junit]     at com.ximpleware.xpath.Step.evalPredicates(Step.java:118)
    [junit]     at com.ximpleware.xpath.Step.eval(Step.java:108)
    [junit]     at
com.ximpleware.LocationPathExpr.process_child(LocationPathExpr.java:291)
    [junit]     at
com.ximpleware.LocationPathExpr.evalNodeSet(LocationPathExpr.java:1556)
    [junit]     at com.ximpleware.UnionExpr.evalNodeSet(UnionExpr.java:111)
    [junit]     at com.ximpleware.AutoPilot.evalXPath(AutoPilot.java:549)
    [junit]     at
com.ximpleware.BinaryExprTest.testCompStringNodeSet(BinaryExprTest.java:28)
    [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit]     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    [junit]     at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Re: [Vtd-xml-users] latest benchmark result

[Jimmy Z. <cra...@co...>]

More data points concerning the performance of DOM and VTD-XML
http://www.javaworld.com/javaworld/jw-01-2007/jw-01-vtd.html

Re: [Vtd-xml-users] latest benchmark result

[Jimmy Z. <cra...@co...>]

A quick update on XPath performance, added test results for Jaxen 1.1

http://www.ximpleware.com/benchmark_xpath.html
----- Original Message ----- 
From: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Thursday, January 04, 2007 6:53 PM
Subject: [Vtd-xml-users] latest benchmark result


> The benchmark report on XPath evaluation performance comparison
>
> http://www.ximpleware.com/benchmark_xpath.html
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
> 

Re: [Vtd-xml-users] BUG: entity problem in toString()

[Jimmy Z. <cra...@co...>]

a typo: 2.0 is due next month,  not next monday...
----- Original Message ----- 
From: "Mark Swanson" <ma...@Sc...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Saturday, January 06, 2007 10:37 AM
Subject: Re: [Vtd-xml-users] BUG: entity problem in toString()


> Jimmy Zhang wrote:
>> Mark, all XPath changes since 1.6 are to make the implemenation faster
>> and more complete... Version 2.0 should come out around the beginning of 
>> the next monday...
>> VTD+XML is the big feature so we want to test everything and benchmark
>> it extensively...
>
> Got it.
> Btw, I haven't had a single problem with 1.6.
>
> Cheers.
>
> -- 
> http://www.ScheduleWorld.com/
> Free Google Calendar synchronization with Outlook, Evolution,
> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.
> 

Re: [Vtd-xml-users] BUG: entity problem in toString()

[Mark S. <ma...@Sc...>]

Jimmy Zhang wrote:
> Mark, all XPath changes since 1.6 are to make the implemenation faster
> and more complete... Version 2.0 should come out around the beginning of 
> the next monday...
> VTD+XML is the big feature so we want to test everything and benchmark
> it extensively...

Got it.
Btw, I haven't had a single problem with 1.6.

Cheers.

-- 
http://www.ScheduleWorld.com/
Free Google Calendar synchronization with Outlook, Evolution,
cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.

Re: [Vtd-xml-users] BUG: entity problem in toString()

[Jimmy Z. <cra...@co...>]

Mark, all XPath changes since 1.6 are to make the implemenation faster
and more complete... 
Version 2.0 should come out around the beginning of the next monday...
VTD+XML is the big feature so we want to test everything and benchmark
it extensively...
Jimmy
----- Original Message ----- 
From: "Mark Swanson" <ma...@Sc...>
To: "Jimmy Zhang" <cra...@co...>
Sent: Saturday, January 06, 2007 9:55 AM
Subject: Re: [Vtd-xml-users] BUG: entity problem in toString()


> Jimmy Zhang wrote:
>> Marc, that problem has now been fixed and checked into CVS...
>> and will be released in 2.0...
>> It is a bug in VTDNav's getCharResolved() method. (1.7 had
>> a rewrite of the method to make it modular, this bug was introduced
>> at that time frame).
>> Thanks for pointing that out...
> 
> ymwc.
> 
> So... when's 2.0 coming out :_)
> 
> I ask because I'm starting to use XPath heavily and with all the XPath 
> changes since 1.6 ... or were all of the XPath changes simply 
> performance improvements?
> 
> Cheers.
> 
> 
> 
> -- 
> http://www.ScheduleWorld.com/
> Free Google Calendar synchronization with Outlook, Evolution,
> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.