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
From: Marius Plavan [mailto:marius.edtf@gmail.com]
Sent: Sunday, June 05, 2011 9:54 AM
To: tamie-comment@lists.oasis-open.org
Subject: [tamie-comment] Event board filter in XTemp CSD2
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