Re: [xmlblaster] get call fix

[Marcel Ruff <mr at marcelruff.info>]

Chris Jones wrote:

> Your suggestion removed the unwanted results, but I am wondering why?  
>
> Using *[((metadata/.....))] should have returned only results that 
> matched and the <key oid="..."> </key> nodes did not contain 
> any matching tree with metadata/... .
>
> Could you explain how adding /xmlblaster/key/metadata fixed this?
Hi Chris,

you can cut and paste the internal DOM from an xmlBlaster dump (type 'd' 
in the console)
just take everything inside the <XmlKeyDom> tag and you have
exactly what the DOM looks inside xmlBlaster.

Put this into a file, lets call it ChrisKey.xml and now you can play 
with XPath:


java DomQueryTest ChrisKey.xml 
"/xmlBlaster/key/metadata/SpecificObjectData[tst_meta/type='CLASSINFO' 
and beginning_date_time_group/hour_time=21]"


(The DomQueryTest is in the xmlBlaster.jar file just to test XPath queries).
The above query returns the matched DOM tree and the found key oids which
a subscriber would subscribe to.

Here is a typical DOM:

<xmlBlaster>
  <key oid="__sys__UserList">
     <__sys__internal />
  </key>
  <key oid="__sys__Login" />
  <key oid="NewSchemaFormat_1.0" domain="DPASA">
     <metadata>
        <BaseObject>
    ...
    </key>
</xmlBlaster>



If you use "*[(( ...." and your expression matches somewhere in the tree,
it will return the COMPLETE tree, our lookup parses the returned tree
to find all key oids -> and it will find ALL oid.

The problem is the "*" which returns everything.
Writing "/xmlBlaster/key" instead selects the matching subtrees
before your expression is applied - and that is what we want.

Note the absolute notation "/xmlBlaster/key/metadata" is much
better performing in XSL as relative notations like "//metadata".

regards

Marcel