[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: eventing - 1.2 wd01 question on use case for a feature.
While reviewing the assembly 1.2 WD 01, I noted an odd detail. Hopefully, the following question will be immediately obvious to someone on the TC, but it wasn't to me. In the bindings section, why in the world does the current draft include filters as a child element of the binding element, when filters also appear in the immediate parent - the containing consumer, producer, or channel? The text says that they can appear for binding specific filtering purposes, but I'm absolutely befuddled by what that means, and what the use-cases might be for this model extension, and I'm concerned by the increased complexity. Can anyone tell me what use cases drive this glorious specificity, or did we just go too far here? While I'm at it, I have more questions. The text on binding.sca notes that the filter element must only appear on bindings specific to channels, producers, and consumers. The generic definition of a binding omits this constraint from its description of the filter element, but that seems like an oversight. Anyone have insight here? This last question highlights an interesting detail. XML Schema has a perfectly good way of making sure that these elements only appear in the appropriate place - by using a new base type definition. So instead of defining all binding elements as having filters, perhaps we should be defining an "eventbinding" that adds an optional filter, rather than repurposing the existing "binding" infrastructure? -Eric.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]