Marius: No explicit update – but because <condition> is optional inside a <match>, its absence should make sense and the only meaningful interpretation seems to the equivalent of “true” – i.e. the next event is caught whatever it is. Similarly, an empty <condition> should be interpreted as an absent <condition> here – i.e. as always “true”. Regards, jacques From: Marius Plavan [mailto:marius.edtf@gmail.com]
Sent: Sunday, December 25, 2011 3:58 AM
To: Jacques Durand; tamie-comment@lists.oasis-open.org
Subject: Re: [tamie-comment] Event board filter in XTemp CSD2 Hi all,
The query looks like this when <condition/> is empty (i.e. see the empty brackets):
//xtemp:event[ () and xsd:integer(@id) gt xsd:integer(0) and ...
Are there any updates on how an empty <condition/> is going to be treated from an XTemp perspective?
Thanks,
Marius Plavan On Sun, Jun 12, 2011 at 2:26 AM, Jacques Durand <JDurand@us.fujitsu.com> wrote: Marius: Indeed the RelaxNG and schemas are correct: filters may be absent, so the text will need to be corrected. The condition may be made mandatory indeed in a filter (although its content still allows “no condition” equivalent, e.g. <condition>fn:true()</condition>) that would at least help developers who forget to put a condition in, when one is needed… And we need to clarify what it means to have an empty condition <condition/> (same as fn:true() probably) Thanks, Jacques Hi all,
I would like to build a simple "memory based" event board based on the /execution-context/event-board element. For this, I looked up in XTemp-csd2.pdf, page 36 and the event board filter has the following compact RelaxNg notation:
---
element xtemp:filter { attribute name { xsd:normalizedString } ?,
element xtemp:condition {condition_body} * } *
---
and the following documentation a few lines below:
---
filter: Besides these attributes, the event-board element contains one or more filters. In a source or
source-sink mode of use, the filter acts as a selector on the events from the physical event store (after
their mapping in XTemp format). The embedded condition - similar in syntax to the match/condition in the
<catch> statement - defines an _expression_ (e.g. XPath) used to select events that are qualified for
posting on the event board. A condition may define a key (@key) that will be associated with the events it
selects. The attribute condition/@key defines an _expression_ which, when evaluated over each selected
event, returns the key value associated with this event.
---
The schema seems to be in line with the compact RelaxNg notation:
---
<xs:element name="filter" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="condition" type="condition_type" minOccurs="0"
/>
</xs:sequence>
<xs:attribute name="name" type="xs:normalizedString" use="optional"
/>
</xs:complexType>
</xs:element>
---
Is the compact RelaxNg notation or the textual description the one to follow (i.e. "one or more filters" vs. "*")?
Also, can the /filter/condition element be missing or it always must be present (as the /filter above)?
From a user perspective at least, I would expect the filter to be specified using "*" or "+" and the condition using "+", as creating a filter without any condition can be avoided by not adding the filter at all.
What do you think?
Regards,
Marius Plavan |