Features/XML Parsing/ParsingRules

From Snom User Wiki

Jump to: navigation, search

ParsingRules extract or create a string from/for an xml. They consist of 0 or more level-tags, each enclosing an Xpath or since 8.7.3 a sip-header evaluation (SHE), eg:

<level1 translates_to="available">
 /tuple[@id=42]/status/basic[.="open"]
</level1>
<level1-1 fetch_content=true>
 Header:Content-ID==<$(ResourceCid)>
</level1-1>
<level2 fetch_attribute="plain">
 /tuple[@id=42]/status
</level2>
<level3 translates_to="unknown"/>

The level determines when to try to match the Xpath or SHE. The search is started with level1, when it doesn't match, level2 is used and so on. To make the resulting string dependent on more then one Xpath or SHE, you can use sub-levels, ie. if you have level1-1, it is evaluated only when level1 matches. If then level1-1 matches, its result is taken, else the result is determined by level1.

When the Xpath or SHE is found in the associated notify, the resulting string is indicated by the attribute in the tag. Those may be(mutually exclusive):

  • translates_to="anyResultingString"
  • fetch_content=true, this will get any plain-text-content the found tag encloses or the sip-header content
  • fetch_attribute="id", this will get the value of the attribute named "id" which should be present in the identified tag

Xpath or SHE may contain $()-placeholders which allow for dynamic insertion of variables and arrays from the xml-entity context (since 8.7.3).

It is good practice to not include a [Features/XML_Parsing/Xpath|Xpath]] or SHE in the highest level-rule (the one evaluated last). This way one can be sure that it matches 100% and the ParsingRules deliver a result.

Personal tools
Interoperability