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

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Hi!

My implementation of setPosition did a binary search for nodes, I 
think... I don't really remember well. The performance was dismal, so 
probably the implementation was wrong... ops! An efficient 
implementation would be great, althought I think depending on the 
situation using SimpleContext could still be better.

Concerning the hash end equals, yep, yor're right... but I was thinking 
perhaps in the future a pointer to the related VTDNav could be 
maintained in SimpleContext, and multiple document mixing in the same 
data structure could be possible... but yeah, I think we could change 
it, despite that new implementation only being consistent in the context 
of a single VTDNav. That specifically  should be put in the 
documentation, of course. Ok, let't keep it simple since class can 
allways be user-derived from SimpleContext implementing multiple VTDNav 
functionality. Basically you're 99% right, with some caveats that should 
perhaps be documented, so let's do it your way :-)

Memory usage is not allways critical, sometimes performance can be 
gained from memory, sometimes that's a false argument. In this case an 
option should be given between fast position recall and small memory 
usage. In fact they are both very small comparing with DOM. My bet is 
that VTD can be better than DOM, even API-wise, and still faster than 
SAX, if we care to enhance the API.



Jimmy Zhang wrote:
> VTD-XML certainly still has a lot of growing up left...
> One old observation from early days of VTD-XML:
> Memory usage has strong performance implications as well...
> DOM's excessive memory usage directly contributes its slow 
> performance, VTD-XML's memory strategy is largely responsible for its 
> parsing performance...so VTD's mentality has always been to: reduce 
> memory usage whenever possible, that will, one way
> or another, lead to better performance...
> as setPosition(int i)'s performance, did your implemenation directly
> manipulate Location Cache tables? I will take a stab at it to see
> how fast it can get
> Concering the equal comparison of two node object, I think that
> the only condition to check is the the currentIndex value of tthe
> cursor location, assuming the same VTDNav instance...
> hashCode computation and equality can basically use that value...

Re: [Vtd-xml-users] Random Access Proposal (take 2)

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

VTD-XML certainly still has a lot of growing up left...
One old observation from early days of VTD-XML:
Memory usage has strong performance implications as well...
DOM's excessive memory usage directly contributes its slow 
performance, VTD-XML's memory strategy is largely responsible 
for its parsing performance...so VTD's mentality has always been to: 
reduce memory usage whenever possible, that will, one way
or another, lead to better performance... 

as setPosition(int i)'s performance, did your implemenation directly
manipulate Location Cache tables? I will take a stab at it to see
how fast it can get 

Concering the equal comparison of two node object, I think that
the only condition to check is the the currentIndex value of tthe
cursor location, assuming the same VTDNav instance...
hashCode computation and equality can basically use that value...




----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Jimmy Zhang" <cra...@co...>
Cc: <vtd...@li...>
Sent: Friday, March 02, 2007 4:46 PM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Hi Jimmy!
> 
> Well, the objective is to hold objects in java data structures for fast 
> access, so I opted for a simple class, with minimal computation 
> requirements. You can see even the equals() ans hashCode() are 
> optimized. It holds a single node because that's the basic building 
> block. All else should be done with container classes, I think: let's 
> not reinvent the wheel, and pretend to do it better.
> 
> All this brings VTD a much needed DOM-like functionality. I can now use 
> VTD as I used DOM before. In fact that's what I've been doing since a 
> few months ago, with my own patched ximpleware-1.6, and I'm now sharing 
> this functionality in a more polished way with you all.
> 
> The code is basically the same as for push and pop, that's right. The 
> wheel was there, worked just fine, I took it and reused it in my own way 
> :-) I gave a simple example because all real code I've produced using 
> this heavily is both confidential and proprietary... so I can't really 
> show that, but believe me, the speed improvements are huge sometimes.
> 
> Memory is cheap and unlimited for most realistic scenarios where this 
> library might be used, processor time is limited. I for one have several 
> GB available, and try to optimize for speed. Sometimes I even disable GC 
> and periodically kill VMs, since that has considerable overall speed 
> gains in some code I developed. Still a SimpleContext can be reused, 
> that that's a good advise if you care both about space and GC.
> 
> I actually made that method you mentioned to recover the position from a 
> single integer. It was kinda slow, to say the least, even with rather 
> optimized search. That was my first try: been there, done that :-) I 
> dumped the code somewhere as it was useless in practice.
> 
> I think SimpleContext, as it is implemented in the last mail I sent, is 
> the best option for random access as I see it, or at least is strongly 
> pointing in the right direction.
> 
> Quite frankly I think all 3 options are excelent, and all should be part 
> of ximpleware-2.1. They are all excelent and different tools, each with 
> a set of critical advantages over others:
> 
> - pop/push
> - NodeRecorder
> - SimpleContext
> 
> Concerning the VTDNav.setPosition(int nodeNumber) I think it's useless, 
> since it's way too slow for heavy usage. But it eventually should be 
> there, just in case, perhaps with some performance-wise warnings.
> 
> I hope this helps improve your wonderfull tool, Jimmy. VTD can really 
> deliver, if you can make it a bit more open and flexible. You can in 
> fact aspire to kill DOM in the future. Perhaps in the future an entire 
> DOM-API could be emulated and implemented on top of VTD, dinamically 
> creating the required objects. For now this is only a dream, of course, 
> but who knows?
> 
> Just my 2 euro-cents :-)
> 
> Jimmy Zhang wrote:
>> Rodrigo, I went over your emails on this thread again and comes up a 
>> few questions...
>>
>> 1. In one of the emails, you attached a class capable of storing a 
>> single node position..
>> I am wondering why store just one? why not more?
>>
>> 2.  In the code below, vn.setCtxFromNav and vn.setNavFromCtx seem to me
>> equivalent to push() and pop
>>
>> myContext = new SimpleContext(null); //Or another size you like, but
>> null works just fine
>> while(ap.iterate()){
>>    vn.setCtxFromNav(myContext);
>>    // do something messy
>>    vn.setNavFromCtx(myContext);
>> }
>>
>>
>> As to NodeRecorder, it is designed to be instantiated once and hold 
>> many nodes...
>> not to be instantiated 10 times for 10 nodes...
>>
>> As to why NodeRecorder doesn't use the node format as in push pop and 
>> setCtx as
>> in your patch... the main motivation is to conserve memory, push pop 
>> and setCtx all
>> use full-expanded node representation which can be quite big for a 
>> complex
>> document
>>
>> NodeRecorde's internal format is more compact, but the the 
>> representation is variable
>> in length...
>>
>> The most compact node representation is to just use the index value 
>> which is always
>> 32-bit per node... VTDNav can add a method that "recovers" the node 
>> position from a
>> single index value of the node...
>>
>> All in all, the above three options are typical trade-offs between 
>> memory and computation
>>
>> * Pop push use the full  expanded node representation which are 
>> constant in length and don't
>> require and extra computation
>>
>> * Node recorder's internal node representation is compacted a bit, but 
>> is variable in length,
>> and therefore can be accessed only sequentially
>>
>> * Using a single integer to represent a node is the most compact, but 
>> requires some CPU cyles
>> to "recover" the node position...
>>
>> I would like ot know what you think of those options...and will take 
>> the discussion
>> forward from that point on...
> 
>

Re: [Vtd-xml-users] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Hi Jimmy!

Well, the objective is to hold objects in java data structures for fast 
access, so I opted for a simple class, with minimal computation 
requirements. You can see even the equals() ans hashCode() are 
optimized. It holds a single node because that's the basic building 
block. All else should be done with container classes, I think: let's 
not reinvent the wheel, and pretend to do it better.

All this brings VTD a much needed DOM-like functionality. I can now use 
VTD as I used DOM before. In fact that's what I've been doing since a 
few months ago, with my own patched ximpleware-1.6, and I'm now sharing 
this functionality in a more polished way with you all.

The code is basically the same as for push and pop, that's right. The 
wheel was there, worked just fine, I took it and reused it in my own way 
:-) I gave a simple example because all real code I've produced using 
this heavily is both confidential and proprietary... so I can't really 
show that, but believe me, the speed improvements are huge sometimes.

Memory is cheap and unlimited for most realistic scenarios where this 
library might be used, processor time is limited. I for one have several 
GB available, and try to optimize for speed. Sometimes I even disable GC 
and periodically kill VMs, since that has considerable overall speed 
gains in some code I developed. Still a SimpleContext can be reused, 
that that's a good advise if you care both about space and GC.

I actually made that method you mentioned to recover the position from a 
single integer. It was kinda slow, to say the least, even with rather 
optimized search. That was my first try: been there, done that :-) I 
dumped the code somewhere as it was useless in practice.

I think SimpleContext, as it is implemented in the last mail I sent, is 
the best option for random access as I see it, or at least is strongly 
pointing in the right direction.

Quite frankly I think all 3 options are excelent, and all should be part 
of ximpleware-2.1. They are all excelent and different tools, each with 
a set of critical advantages over others:

- pop/push
- NodeRecorder
- SimpleContext

Concerning the VTDNav.setPosition(int nodeNumber) I think it's useless, 
since it's way too slow for heavy usage. But it eventually should be 
there, just in case, perhaps with some performance-wise warnings.

I hope this helps improve your wonderfull tool, Jimmy. VTD can really 
deliver, if you can make it a bit more open and flexible. You can in 
fact aspire to kill DOM in the future. Perhaps in the future an entire 
DOM-API could be emulated and implemented on top of VTD, dinamically 
creating the required objects. For now this is only a dream, of course, 
but who knows?

Just my 2 euro-cents :-)

Jimmy Zhang wrote:
> Rodrigo, I went over your emails on this thread again and comes up a 
> few questions...
>
> 1. In one of the emails, you attached a class capable of storing a 
> single node position..
> I am wondering why store just one? why not more?
>
> 2.  In the code below, vn.setCtxFromNav and vn.setNavFromCtx seem to me
> equivalent to push() and pop
>
> myContext = new SimpleContext(null); //Or another size you like, but
> null works just fine
> while(ap.iterate()){
>    vn.setCtxFromNav(myContext);
>    // do something messy
>    vn.setNavFromCtx(myContext);
> }
>
>
> As to NodeRecorder, it is designed to be instantiated once and hold 
> many nodes...
> not to be instantiated 10 times for 10 nodes...
>
> As to why NodeRecorder doesn't use the node format as in push pop and 
> setCtx as
> in your patch... the main motivation is to conserve memory, push pop 
> and setCtx all
> use full-expanded node representation which can be quite big for a 
> complex
> document
>
> NodeRecorde's internal format is more compact, but the the 
> representation is variable
> in length...
>
> The most compact node representation is to just use the index value 
> which is always
> 32-bit per node... VTDNav can add a method that "recovers" the node 
> position from a
> single index value of the node...
>
> All in all, the above three options are typical trade-offs between 
> memory and computation
>
> * Pop push use the full  expanded node representation which are 
> constant in length and don't
> require and extra computation
>
> * Node recorder's internal node representation is compacted a bit, but 
> is variable in length,
> and therefore can be accessed only sequentially
>
> * Using a single integer to represent a node is the most compact, but 
> requires some CPU cyles
> to "recover" the node position...
>
> I would like ot know what you think of those options...and will take 
> the discussion
> forward from that point on...

Re: [Vtd-xml-users] Random Access Proposal (take 2)

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

Rodrigo, I went over your emails on this thread again and comes up a few 
questions...

1. In one of the emails, you attached a class capable of storing a single 
node position..
I am wondering why store just one? why not more?

2.  In the code below, vn.setCtxFromNav and vn.setNavFromCtx seem to me
equivalent to push() and pop

myContext = new SimpleContext(null); //Or another size you like, but
null works just fine
while(ap.iterate()){
    vn.setCtxFromNav(myContext);
    // do something messy
    vn.setNavFromCtx(myContext);
}


As to NodeRecorder, it is designed to be instantiated once and hold many 
nodes...
not to be instantiated 10 times for 10 nodes...

As to why NodeRecorder doesn't use the node format as in push pop and setCtx 
as
in your patch... the main motivation is to conserve memory, push pop and 
setCtx all
use full-expanded node representation which can be quite big for a complex
document

NodeRecorde's internal format is more compact, but the the representation is 
variable
in length...

The most compact node representation is to just use the index value which is 
always
32-bit per node... VTDNav can add a method that "recovers" the node position 
from a
single index value of the node...

All in all, the above three options are typical trade-offs between memory 
and computation

* Pop push use the full  expanded node representation which are constant in 
length and don't
require and extra computation

* Node recorder's internal node representation is compacted a bit, but is 
variable in length,
and therefore can be accessed only sequentially

* Using a single integer to represent a node is the most compact, but 
requires some CPU cyles
to "recover" the node position...

I would like ot know what you think of those options...and will take the 
discussion
forward from that point on...





----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: <vtd...@li...>
Sent: Thursday, February 15, 2007 3:19 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Well, just some ideas concerning what I think should be the nature of a
> "context":
>
> - As light as possible to generate, manipulate and access (so just use a
> simple context with minimun clutter).
> - Comparable.
> - Hashable efficiently (good and fast dispertion function).
> - Possible to associate with VTDNav (so contains a pointer to VTDNav).
> - Usable in another VTDNav (that's a tricky one, and unsafe, but makes
> sense if you have various equal VTDNavs and a RMI-based system, so it
> should be possible despite perhaps including dire warnings in the
> documentation).
>
> Jimmy Zhang wrote:
>
> Yes, will try, but then again, there will always be a 2.1 :)
>
>
> -------------------------------------------------------------------------
> 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] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Mark (et all.), you can try my random access API now if you want.

The code is working and tested while processing very large and complex XML.

As I previously said, the API can be used in a very simple way:

SimpleContext ctx = new SimpleContext();
navigator.setCtxFromNav(ctx); // hold context
// do whatever you want
navigator.setNavFromCtx(ctx); // return to the context

The code of SimpleContext is very easy and understandable. The code for 
the functions in VTDNav is also very simple, and basically a copy+paste 
of the code used for stack memory.

Both hashCode() and equals() are implemented in an efficient way 
(untested...) so that contexts can be kept in structures requiring such 
attributes.

Also the context class can be created in large numbers, since it's so 
lightweight.

You just need to recompile ximpleware-2.0 using my 2 files, included 
here as attachements.

New ideas, bug reports, etc, are welcomed :-)

Re: [Vtd-xml-users] Random Access Proposal (take 2)

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

Jimmy Zhang wrote:
> I believe you can relative location path for that
> instead of using /ccc/*
> you only need to say         ccc
> (relative location path is basically loation paths
> that don't start from root)

I was speaking from the point of view where 'ccc' was the new document 
root, so /ccc/* would be what I want.

Note: ccc wouldn't have to be the document root, it just seems nicer to 
me atm to deal with mini documents aggregated into a larger document. 
The xpath for querying snippets of xml would be simpler - some cases 
much simpler as you don't even have to know the crud required to get to 
the indexed element.

Cheers.

> ----- Original Message ----- 
> From: "Mark Swanson" <ma...@Sc...>
> To: "Rodrigo Cunha" <rn...@gm...>
> Cc: <vtd...@li...>
> Sent: Wednesday, February 28, 2007 6:56 PM
> Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)
> 
> 
>> Rodrigo Cunha wrote:
>>> For a SimpleContext, or something similar:
>>>
>>> The comparison operator could just compare the arrays containing the
>>> internal state of Navigator.
>>>
>>> The hashcode would be the XOR of all elements in the array, that
>>> implements java hashcode and equals in a compatible way with the assumed
>>> rules in java libraries.
>>>
>>> Jimmy, I think my "SimpleContext" or whatever you want to call it, if
>>> properly implemented and perhaps with a few extra functions  could solve
>>> all the problems of random access.
>>>
>>> I think we just want something with the functionality of push() and
>>> pop() but that can be extracted and kept outside, memorizing the
>>> equivalent of a single stack position, and perhaps with a bit more
>>> functionality.
>> It will be interesting to see how much / little info we can get away
>> with saving and still be able to start an XPath expression from an
>> arbitrary point.
>>
>> Important: it may make the implementation easier if we make the
>> arbitrary starting point the new document root - just for xpath
>> evaluation purposes. I think this is perfect, actually. I don't want
>> anything except for the node and its children - that's why I'm
>> explicitly pointing there in the first place.
>>
>> F.E.
>> (forgive the illegal simplified syntax..)
>>
>> aaa
>>   bbb
>>     ccc    <- Index saved, new root for xpath eval.
>>       eee
>>       fff
>>     /ccc
>>     dd
>> ...
>>
>> I'd want to say something like this:
>>
>> vtdNav.toElement(cccIndex); // reset cursor to ccc
>> ap.selectXPath("/ccc/*")


-- 
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] Random Access Proposal (take 2)

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

I am doing an article that explains Xpath part of VTD-XML...
I will get you a sneek preview since I am using google's doc services,
which allows me to publish the content...
----- Original Message ----- 
From: "Mark Swanson" <ma...@Sc...>
To: "Rodrigo Cunha" <rn...@gm...>
Cc: <vtd...@li...>
Sent: Wednesday, February 28, 2007 7:51 PM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Rodrigo Cunha wrote:
>> Nah... given what i understand about the internal structure making it
>> the new document root is not trivial, i think.
>>
>> But you could get away with:
>>
>> - A bookmark/position saving system, aka the (in)famous SimpleContext
>> class?...
>>
>> - A function evaluating:
>>
>> boolean SimpleContext.isSunOf(Simplecontext ctx); //this should be
>> simple and efficient to implement
>
> You would know better than me. I have a high level requirement to be
> able to jump to a point and do XPath on it. It doesn't have to be the
> new document root - I just thought that might be easier. If your
> SimpleContext class will help me get there then I'm all for it.
>
> 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.
>
> -------------------------------------------------------------------------
> 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] Random Access Proposal (take 2)

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

I need to give that some thought...
----- Original Message ----- 
From: "Rodrigo Cunha" <rn...@gm...>
To: "Mark Swanson" <ma...@Sc...>
Cc: <vtd...@li...>
Sent: Wednesday, February 28, 2007 7:20 PM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Nah... given what i understand about the internal structure making it
> the new document root is not trivial, i think.
>
> But you could get away with:
>
> - A bookmark/position saving system, aka the (in)famous SimpleContext
> class?...
>
> - A function evaluating:
>
> boolean SimpleContext.isSunOf(Simplecontext ctx); //this should be
> simple and efficient to implement
>
> Regards,
>
> Rodrigo
>
> Mark Swanson wrote:
>> Rodrigo Cunha wrote:
>>> For a SimpleContext, or something similar:
>>>
>>> The comparison operator could just compare the arrays containing the
>>> internal state of Navigator.
>>>
>>> The hashcode would be the XOR of all elements in the array, that
>>> implements java hashcode and equals in a compatible way with the
>>> assumed rules in java libraries.
>>>
>>> Jimmy, I think my "SimpleContext" or whatever you want to call it, if
>>> properly implemented and perhaps with a few extra functions  could
>>> solve all the problems of random access.
>>>
>>> I think we just want something with the functionality of push() and
>>> pop() but that can be extracted and kept outside, memorizing the
>>> equivalent of a single stack position, and perhaps with a bit more
>>> functionality.
>>
>> It will be interesting to see how much / little info we can get away
>> with saving and still be able to start an XPath expression from an
>> arbitrary point.
>>
>> Important: it may make the implementation easier if we make the
>> arbitrary starting point the new document root - just for xpath
>> evaluation purposes. I think this is perfect, actually. I don't want
>> anything except for the node and its children - that's why I'm
>> explicitly pointing there in the first place.
>>
>> F.E.
>> (forgive the illegal simplified syntax..)
>>
>> aaa
>>   bbb
>>     ccc    <- Index saved, new root for xpath eval.
>>       eee
>>       fff
>>     /ccc
>>     dd
>> ...
>>
>> I'd want to say something like this:
>>
>> vtdNav.toElement(cccIndex); // reset cursor to ccc
>> ap.selectXPath("/ccc/*")
>>
>> Cheers.
>>
>
>
> -------------------------------------------------------------------------
> 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] Random Access Proposal (take 2)

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

I believe you can relative location path for that
instead of using /ccc/*
you only need to say         ccc
(relative location path is basically loation paths
that don't start from root)
----- Original Message ----- 
From: "Mark Swanson" <ma...@Sc...>
To: "Rodrigo Cunha" <rn...@gm...>
Cc: <vtd...@li...>
Sent: Wednesday, February 28, 2007 6:56 PM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Rodrigo Cunha wrote:
>> For a SimpleContext, or something similar:
>>
>> The comparison operator could just compare the arrays containing the
>> internal state of Navigator.
>>
>> The hashcode would be the XOR of all elements in the array, that
>> implements java hashcode and equals in a compatible way with the assumed
>> rules in java libraries.
>>
>> Jimmy, I think my "SimpleContext" or whatever you want to call it, if
>> properly implemented and perhaps with a few extra functions  could solve
>> all the problems of random access.
>>
>> I think we just want something with the functionality of push() and
>> pop() but that can be extracted and kept outside, memorizing the
>> equivalent of a single stack position, and perhaps with a bit more
>> functionality.
>
> It will be interesting to see how much / little info we can get away
> with saving and still be able to start an XPath expression from an
> arbitrary point.
>
> Important: it may make the implementation easier if we make the
> arbitrary starting point the new document root - just for xpath
> evaluation purposes. I think this is perfect, actually. I don't want
> anything except for the node and its children - that's why I'm
> explicitly pointing there in the first place.
>
> F.E.
> (forgive the illegal simplified syntax..)
>
> aaa
>   bbb
>     ccc    <- Index saved, new root for xpath eval.
>       eee
>       fff
>     /ccc
>     dd
> ...
>
> I'd want to say something like this:
>
> vtdNav.toElement(cccIndex); // reset cursor to ccc
> ap.selectXPath("/ccc/*")
>
> 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.
>
> -------------------------------------------------------------------------
> 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] Random Access Proposal (take 2)

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

--- Rodrigo Cunha <rn...@gm...> wrote:

> Nah... given what i understand about the internal
> structure making it 
> the new document root is not trivial, i think.

I guess there are two different cases: one of using as
context node (which seems trivially easy), where it
doesn't limit xpath from going up the hierarchy; and
the other that would essentially force a sub-tree to
be new "sub-document" (so that xpath traversal would
never go up past the sub-tree root). Latter would be
only little bit more complicated unless I'm missing
something.

I mean, xpath processing code uses int indexes for
traversing different axes; and it should be able to
limit its visibility to sub-tree, which is just
int-range (node-start-offset - to -
next-sibling-offset-minus-1). That's one benefit of
using consequtive int indexes, defining sub-trees is
rather simple.

-+ Tatu +-



 
____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

Re: [Vtd-xml-users] Random Access Proposal (take 2)

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

Rodrigo Cunha wrote:
> Nah... given what i understand about the internal structure making it 
> the new document root is not trivial, i think.
> 
> But you could get away with:
> 
> - A bookmark/position saving system, aka the (in)famous SimpleContext 
> class?...
> 
> - A function evaluating:
> 
> boolean SimpleContext.isSunOf(Simplecontext ctx); //this should be 
> simple and efficient to implement

You would know better than me. I have a high level requirement to be 
able to jump to a point and do XPath on it. It doesn't have to be the 
new document root - I just thought that might be easier. If your 
SimpleContext class will help me get there then I'm all for it.

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] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

Nah... given what i understand about the internal structure making it 
the new document root is not trivial, i think.

But you could get away with:

- A bookmark/position saving system, aka the (in)famous SimpleContext 
class?...

- A function evaluating:

boolean SimpleContext.isSunOf(Simplecontext ctx); //this should be 
simple and efficient to implement

Regards,

Rodrigo

Mark Swanson wrote:
> Rodrigo Cunha wrote:
>> For a SimpleContext, or something similar:
>>
>> The comparison operator could just compare the arrays containing the 
>> internal state of Navigator.
>>
>> The hashcode would be the XOR of all elements in the array, that 
>> implements java hashcode and equals in a compatible way with the 
>> assumed rules in java libraries.
>>
>> Jimmy, I think my "SimpleContext" or whatever you want to call it, if 
>> properly implemented and perhaps with a few extra functions  could 
>> solve all the problems of random access.
>>
>> I think we just want something with the functionality of push() and 
>> pop() but that can be extracted and kept outside, memorizing the 
>> equivalent of a single stack position, and perhaps with a bit more 
>> functionality.
>
> It will be interesting to see how much / little info we can get away 
> with saving and still be able to start an XPath expression from an 
> arbitrary point.
>
> Important: it may make the implementation easier if we make the 
> arbitrary starting point the new document root - just for xpath 
> evaluation purposes. I think this is perfect, actually. I don't want 
> anything except for the node and its children - that's why I'm 
> explicitly pointing there in the first place.
>
> F.E.
> (forgive the illegal simplified syntax..)
>
> aaa
>   bbb
>     ccc    <- Index saved, new root for xpath eval.
>       eee
>       fff
>     /ccc
>     dd
> ...
>
> I'd want to say something like this:
>
> vtdNav.toElement(cccIndex); // reset cursor to ccc
> ap.selectXPath("/ccc/*")
>
> Cheers.
>

Re: [Vtd-xml-users] Random Access Proposal (take 2)

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

Rodrigo Cunha wrote:
> For a SimpleContext, or something similar:
> 
> The comparison operator could just compare the arrays containing the 
> internal state of Navigator.
> 
> The hashcode would be the XOR of all elements in the array, that 
> implements java hashcode and equals in a compatible way with the assumed 
> rules in java libraries.
> 
> Jimmy, I think my "SimpleContext" or whatever you want to call it, if 
> properly implemented and perhaps with a few extra functions  could solve 
> all the problems of random access.
> 
> I think we just want something with the functionality of push() and 
> pop() but that can be extracted and kept outside, memorizing the 
> equivalent of a single stack position, and perhaps with a bit more 
> functionality.

It will be interesting to see how much / little info we can get away 
with saving and still be able to start an XPath expression from an 
arbitrary point.

Important: it may make the implementation easier if we make the 
arbitrary starting point the new document root - just for xpath 
evaluation purposes. I think this is perfect, actually. I don't want 
anything except for the node and its children - that's why I'm 
explicitly pointing there in the first place.

F.E.
(forgive the illegal simplified syntax..)

aaa
   bbb
     ccc    <- Index saved, new root for xpath eval.
       eee
       fff
     /ccc
     dd
...

I'd want to say something like this:

vtdNav.toElement(cccIndex); // reset cursor to ccc
ap.selectXPath("/ccc/*")

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] Random Access Proposal (take 2)

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

Tatu Saloranta wrote:
> --- Mark Swanson <ma...@Sc...> wrote:
> 
> ...
>> It would be most helpful to me if I could index
>> arbitrary element 
>> indexes and start and XPath query from one of these
>> indexes. I would 
>> cache these indexes in a Map with key: some unique
>> ID, value: some sort 
>> of vtd-xml node index.
> 
> Given that VTD-XML indices are, well, ints, would this
> be anything more than a kind of Map<String,int>? (or,
> a stack thereof).
> That seems like a simple thing to build even outside
> of VTD-XML itself?
> 
> Just curious,

Good point. If Jimmy can rig it so I can just execute arbitrary XPath 
expressions starting from a specific node this might be too easy.
I'm a little worried about starting an XPath evaluation from a specific 
spot though. Hopefully Jimmy has some insight on that.

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] Random Access Proposal (take 2)

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

Jimmy Zhang wrote:
> Mark, I believe the first thing your described, which is to index
> a node position from which an XPath eval can start, is already possible
> a custom hack should available...
> As to node id and hashmap part, what do you think about the index
> of a VTD record, it is always unique within a given XML doc,what
> do you think of that?

I think using the VTD record index is perfect.
Requirement: I want to use different XPaths.

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.

[Vtd-xml-users] [Fwd: Re: Random Access Proposal (take 2)]

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

Rodrigo Cunha wrote:
> Mark, my implementation has some bug... it doesn't really work, but just 
> let me know if the API is ok to you.
> 
> We can iron-out bugs latter, with Jimmy help perhaps :-)
> 
> You can create a SimpleContext, witch holds a position, with:
> 
> SimpleContext ctx = new SimpleContext(null);
> //starts as an empty context
> 
> or
> 
> SimpleContext ctx = new SimpleContext(int size);
> // starts with given nodes capacity, so reallocation can be minimized 
> during reuse
> 
> and you can use the object to hold and retrieve positions with:
> 
> navigator.setCtxFromNav(ctx);
> //holds current position in this context object
> 
> and
> 
> navigator.setNavFromCtx(ctx);
> //sets navigator pointers from this context object
> 
> 
> The object itself has little storage requirements, only a small integer 
> array, so you can create thousands and still live happy.
> 
> They are also reusable, to minimize garbage collection just in case your 
> algoritm wants to reuse them.
> 
> Does this sound ok for you, Mark?

I'm not sure. Jimmy and Tatu have the interesting idea about Map<String,
int> and running an XPath from the int (node index). I like that! In my
case, it would be Map<int, int> with both ints non-objects using fastutils.

Do you think some thing as simple as this would be too simple for your
use cases?

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.


-- 
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] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
For a SimpleContext, or something similar:<br>
<br>
The comparison operator could just compare the arrays containing the
internal state of Navigator.<br>
<br>
The hashcode would be the XOR of all elements in the array, that
implements java hashcode and equals in a compatible way with the
assumed rules in java libraries.<br>
<br>
Jimmy, I think my "SimpleContext" or whatever you want to call it, if
properly implemented and perhaps with a few extra functions&nbsp; could
solve all the problems of random access.<br>
<br>
I think we just want something with the functionality of push() and
pop() but that can be extracted and kept outside, memorizing the
equivalent of a single stack position, and perhaps with a bit more
functionality.<br>
<br>
Jimmy Zhang wrote:
<blockquote cite="mid007001c75b8c$f5e9fc90$0d02a8c0@ximpleware"
 type="cite">
  <pre wrap="">sounds good to me...


----- Original Message ----- 
From: "Tatu Saloranta" <a class="moz-txt-link-rfc2396E" href="mailto:cow...@ya...">&lt;cow...@ya...&gt;</a>
To: <a class="moz-txt-link-rfc2396E" href="mailto:vtd...@li...">&lt;vtd...@li...&gt;</a>
Sent: Wednesday, February 28, 2007 2:59 PM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


  </pre>
  <blockquote type="cite">
    <pre wrap="">--- Mark Swanson <a class="moz-txt-link-rfc2396E" href="mailto:ma...@Sc...">&lt;ma...@Sc...&gt;</a> wrote:

...
    </pre>
    <blockquote type="cite">
      <pre wrap="">It would be most helpful to me if I could index
arbitrary element
indexes and start and XPath query from one of these
indexes. I would
cache these indexes in a Map with key: some unique
ID, value: some sort
of vtd-xml node index.
      </pre>
    </blockquote>
    <pre wrap="">Given that VTD-XML indices are, well, ints, would this
be anything more than a kind of Map&lt;String,int&gt;? (or,
a stack thereof).
That seems like a simple thing to build even outside
of VTD-XML itself?

Just curious,

-+ Tatu +-




____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut.
<a class="moz-txt-link-freetext" href="http://tools.search.yahoo.com/shortcuts/#news">http://tools.search.yahoo.com/shortcuts/#news</a>

-------------------------------------------------------------------------
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 &amp; business topics through brief surveys-and earn cash
<a class="moz-txt-link-freetext" href="http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV">http://www.techsay.com/default.php?page=join.php&amp;p=sourceforge&amp;CID=DEVDEV</a>
_______________________________________________
Vtd-xml-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Vtd...@li...">Vtd...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/vtd-xml-users">https://lists.sourceforge.net/lists/listinfo/vtd-xml-users</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->


-------------------------------------------------------------------------
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 &amp; business topics through brief surveys-and earn cash
<a class="moz-txt-link-freetext" href="http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV">http://www.techsay.com/default.php?page=join.php&amp;p=sourceforge&amp;CID=DEVDEV</a>
_______________________________________________
Vtd-xml-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Vtd...@li...">Vtd...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/vtd-xml-users">https://lists.sourceforge.net/lists/listinfo/vtd-xml-users</a>

  </pre>
</blockquote>
<br>
</body>
</html>

Re: [Vtd-xml-users] Random Access Proposal (take 2)

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

sounds good to me...


----- Original Message ----- 
From: "Tatu Saloranta" <cow...@ya...>
To: <vtd...@li...>
Sent: Wednesday, February 28, 2007 2:59 PM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> --- Mark Swanson <ma...@Sc...> wrote:
>
> ...
>> It would be most helpful to me if I could index
>> arbitrary element
>> indexes and start and XPath query from one of these
>> indexes. I would
>> cache these indexes in a Map with key: some unique
>> ID, value: some sort
>> of vtd-xml node index.
>
> Given that VTD-XML indices are, well, ints, would this
> be anything more than a kind of Map<String,int>? (or,
> a stack thereof).
> That seems like a simple thing to build even outside
> of VTD-XML itself?
>
> Just curious,
>
> -+ Tatu +-
>
>
>
>
> ____________________________________________________________________________________
> 8:00? 8:25? 8:40? Find a flick in no time
> with the Yahoo! Search movie showtime shortcut.
> http://tools.search.yahoo.com/shortcuts/#news
>
> -------------------------------------------------------------------------
> 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] Random Access Proposal (take 2)

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

--- Mark Swanson <ma...@Sc...> wrote:

...
> It would be most helpful to me if I could index
> arbitrary element 
> indexes and start and XPath query from one of these
> indexes. I would 
> cache these indexes in a Map with key: some unique
> ID, value: some sort 
> of vtd-xml node index.

Given that VTD-XML indices are, well, ints, would this
be anything more than a kind of Map<String,int>? (or,
a stack thereof).
That seems like a simple thing to build even outside
of VTD-XML itself?

Just curious,

-+ Tatu +-



 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

Re: [Vtd-xml-users] Random Access Proposal (take 2)

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

Mark, when you save a node position, then later want to
start the xpath from that node position, are you talking about
the same xpath (one which you use to locate the node in
the first place) or a different one?
Jimmy
----- Original Message ----- 
From: "Mark Swanson" <ma...@Sc...>
To: <vtd...@li...>
Sent: Wednesday, February 28, 2007 8:11 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Rodrigo Cunha wrote:
>> I understand NodeRecorder was not intended to be kept in large numbers,
>> but I think that should exactly be the idea of a random access API: a
>> lightweight way of keeping a bunch of bookmarks in the datastructure the
>> programmer wants, not in the structure we want, or something...
>>
>> Your API is nice for somewhat serial processing, not for true random
>> access, using pre-build hash tables, for example, or trees, or whatever.
>> I could built a wrapper around NodeRecorder implementing a simplier API,
>> but that would be really clumsy.
>>
>> My API, while incomplete, is much more simple, and flexible also... it's
>> also rather light. I would like to learn about other opinions on the
>> subject, since we are probably both too used to our way of doing things
>> to be impartial.
>
> It would be most helpful to me if I could index arbitrary element
> indexes and start and XPath query from one of these indexes. I would
> cache these indexes in a Map with key: some unique ID, value: some sort
> of vtd-xml node index.
>
> For most of the applications I use XML for, this would be the only way
> to get acceptable performance. Ultimately, without this I would not be
> able to consider using vtd-xml for these apps and I would be forced to
> use an xml - Object mapping tool.
>
> I've been using and helping maintain/fix a number of XML - Object
> mapping tools over the years. It's been an interesting area of study for
> me. Please free me from the insufferable weight of those chains :-)
>
> 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.
>
> -------------------------------------------------------------------------
> 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] Random Access Proposal (take 2)

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

Mark, I believe the first thing your described, which is to index
a node position from which an XPath eval can start, is already possible
a custom hack should available...
As to node id and hashmap part, what do you think about the index
of a VTD record, it is always unique within a given XML doc,what
do you think of that?
----- Original Message ----- 
From: "Mark Swanson" <ma...@Sc...>
To: <vtd...@li...>
Sent: Wednesday, February 28, 2007 8:11 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Rodrigo Cunha wrote:
>> I understand NodeRecorder was not intended to be kept in large numbers,
>> but I think that should exactly be the idea of a random access API: a
>> lightweight way of keeping a bunch of bookmarks in the datastructure the
>> programmer wants, not in the structure we want, or something...
>>
>> Your API is nice for somewhat serial processing, not for true random
>> access, using pre-build hash tables, for example, or trees, or whatever.
>> I could built a wrapper around NodeRecorder implementing a simplier API,
>> but that would be really clumsy.
>>
>> My API, while incomplete, is much more simple, and flexible also... it's
>> also rather light. I would like to learn about other opinions on the
>> subject, since we are probably both too used to our way of doing things
>> to be impartial.
>
> It would be most helpful to me if I could index arbitrary element
> indexes and start and XPath query from one of these indexes. I would
> cache these indexes in a Map with key: some unique ID, value: some sort
> of vtd-xml node index.
>
> For most of the applications I use XML for, this would be the only way
> to get acceptable performance. Ultimately, without this I would not be
> able to consider using vtd-xml for these apps and I would be forced to
> use an xml - Object mapping tool.
>
> I've been using and helping maintain/fix a number of XML - Object
> mapping tools over the years. It's been an interesting area of study for
> me. Please free me from the insufferable weight of those chains :-)
>
> 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.
>
> -------------------------------------------------------------------------
> 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] What about schema Validation ?

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

MessageWe are working on Schema validation part, the plan is to offer a =
subset of XSD
first, then expand on top of that... relaxNG is something we are =
planning to support
as well...
if you have any suggestions or feature requrest, feel free to go to =
sourceforge and file
a enhancment request...
  ----- Original Message -----=20
  From: Ludovic Mussier=20
  To: vtd...@li...=20
  Sent: Wednesday, February 28, 2007 9:09 AM
  Subject: [Vtd-xml-users] What about schema Validation ?


  Hi,=20

  =20

  We are split between the real power of VTD-XML and the impossibility =
to validate XML content with VTD-XML.

  Is there any information about the further availably a validation =
feature in VTD-XML?

  =20



-------------------------------------------------------------------------=
-----


  =
-------------------------------------------------------------------------=

  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=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV


-------------------------------------------------------------------------=
-----


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

Re: [Vtd-xml-users] Random Access Proposal (take 2)

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

Rodrigo,
    Can you explain the hash table a bit more? I am especially interested
in when it would helpful to you... also I would like to know if you think
there are alterantives...

    From my perspective, offering something you described
is definitely what we strive to achieve, however, when we design/enhance
an API, everything we add can potentially be a double-edged sword,

    Take nodeRecorder as an example..it offers some degree of random
access, but if not used properly it will consume much memory, also I have
been a bit busy lately with some other stuff..

   let me get to some of your old emails the next few days and get back to 
you...

----- Original Message ----- 
From: "Mark Swanson" <ma...@Sc...>
To: <vtd...@li...>
Sent: Wednesday, February 28, 2007 8:11 AM
Subject: Re: [Vtd-xml-users] Random Access Proposal (take 2)


> Rodrigo Cunha wrote:
>> I understand NodeRecorder was not intended to be kept in large numbers,
>> but I think that should exactly be the idea of a random access API: a
>> lightweight way of keeping a bunch of bookmarks in the datastructure the
>> programmer wants, not in the structure we want, or something...
>>
>> Your API is nice for somewhat serial processing, not for true random
>> access, using pre-build hash tables, for example, or trees, or whatever.
>> I could built a wrapper around NodeRecorder implementing a simplier API,
>> but that would be really clumsy.
>>
>> My API, while incomplete, is much more simple, and flexible also... it's
>> also rather light. I would like to learn about other opinions on the
>> subject, since we are probably both too used to our way of doing things
>> to be impartial.
>
> It would be most helpful to me if I could index arbitrary element
> indexes and start and XPath query from one of these indexes. I would
> cache these indexes in a Map with key: some unique ID, value: some sort
> of vtd-xml node index.
>
> For most of the applications I use XML for, this would be the only way
> to get acceptable performance. Ultimately, without this I would not be
> able to consider using vtd-xml for these apps and I would be forced to
> use an xml - Object mapping tool.
>
> I've been using and helping maintain/fix a number of XML - Object
> mapping tools over the years. It's been an interesting area of study for
> me. Please free me from the insufferable weight of those chains :-)
>
> 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.
>
> -------------------------------------------------------------------------
> 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] Random Access Proposal (take 2)

[Rodrigo C. <rn...@gm...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mark, my implementation has some bug... it doesn't really work, but
just let me know if the API is ok to you.<br>
<br>
We can iron-out bugs latter, with Jimmy help perhaps :-)<br>
<br>
You can create a SimpleContext, witch holds a position, with:<br>
<br>
SimpleContext ctx = new SimpleContext(null);<br>
//starts as an empty context<br>
<br>
or<br>
<br>
SimpleContext ctx = new SimpleContext(int size);<br>
// starts with given nodes capacity, so reallocation can be minimized
during reuse<br>
<br>
and you can use the object to hold and retrieve positions with:<br>
<br>
navigator.setCtxFromNav(ctx);<br>
//holds current position in this context object<br>
<br>
and<br>
<br>
navigator.setNavFromCtx(ctx);<br>
//sets navigator pointers from this context object<br>
<br>
<br>
The object itself has little storage requirements, only a small integer
array, so you can create thousands and still live happy.<br>
<br>
They are also reusable, to minimize garbage collection just in case
your algoritm wants to reuse them.<br>
<br>
Does this sound ok for you, Mark?<br>
<br>
<br>
<br>
Mark Swanson wrote:
<blockquote cite="mid...@Sc..." type="cite">
  <pre wrap="">Rodrigo Cunha wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I understand NodeRecorder was not intended to be kept in large numbers, 
but I think that should exactly be the idea of a random access API: a 
lightweight way of keeping a bunch of bookmarks in the datastructure the 
programmer wants, not in the structure we want, or something...

Your API is nice for somewhat serial processing, not for true random 
access, using pre-build hash tables, for example, or trees, or whatever. 
I could built a wrapper around NodeRecorder implementing a simplier API, 
but that would be really clumsy.

My API, while incomplete, is much more simple, and flexible also... it's 
also rather light. I would like to learn about other opinions on the 
subject, since we are probably both too used to our way of doing things 
to be impartial.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It would be most helpful to me if I could index arbitrary element 
indexes and start and XPath query from one of these indexes. I would 
cache these indexes in a Map with key: some unique ID, value: some sort 
of vtd-xml node index.

For most of the applications I use XML for, this would be the only way 
to get acceptable performance. Ultimately, without this I would not be 
able to consider using vtd-xml for these apps and I would be forced to 
use an xml - Object mapping tool.

I've been using and helping maintain/fix a number of XML - Object 
mapping tools over the years. It's been an interesting area of study for 
me. Please free me from the insufferable weight of those chains :-)

Cheers.

  </pre>
</blockquote>
<br>
</body>
</html>

[Vtd-xml-users] What about schema Validation ?

[Ludovic M. <lud...@so...>]

Hi, 

 

We are split between the real power of VTD-XML and the impossibility to
validate XML content with VTD-XML.

Is there any information about the further availably a validation
feature in VTD-XML?