On 1/11/11 2:08 AM, Peter Niblett wrote:
type="cite">2. The other
part of the issue concerns
the name of the event body filter. As I said in my email of Sept
22, there are three things that the filter syntax has to express.
i) The type of data that the filter operates against (the
ii). The language used to
filter (the dialect)
iii). The filter expression
It is helpful to retain the
of i) and ii), as it allows you to tell what the subject is,
if you don't recognise the dialect. If we just had a flat name
define my own filter expression - say Peter_special_no_22 -
would not be possible to tell what kind of filter it is. Also
you do a have a dialect used for more than one subject (e.g.
for both body and metadata) you only have to define its syntax
once. I actually
prefer a syntax where the dialect is expressed as an attribute
what happens in WS-Notification and WS-Eventing), e.g.
but I understand that the TC
an approach where we include the dialect as part of the
element name, so
I am ok with that,
I actually would be OK with that approach as well. So I wouldn't
assume the will of the TC on this point. I have done so, because I
was not attending Assembly TC meetings when this element was first
introduced, and nobody has stepped up to offer this alternative.
But perhaps that was a mistake?
3. This is what we have in the
qnames="list of xs:QName"? namespaces="list of xs:anyURI"?
I agree with Anish that we
the word "filter" in the filter QName, since these elements
all children of the <filters> element.
As I stated in my proposal, I actually think the other entry should
be changed to "eventTypeFilter.sca". I think this is an odd place to
start applying brevity to something represented in XML. If we're
talking about global element definitions, then I think a fully
spelled out name is appropriate. If we want to change the schema so
that these elements are defined locally to the "filters" element,
then I'd agree that we can drop the "filter" from the name.
4. I think it we should have
consistent appearance for the two filter names (and any others
we may introduce
in the future). Changing <body.xpath1> to
or <bodyXpath1> makes the body filter syntax and the
syntax inconsistent (in comparison with the consistent syntax
As I understand things, the
is that we cannot use a . in the body name, since the element
using a substitution group and everywhere else in SCA assembly
a . implies
the substitution group. This is indeed the case.. here is the
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="sca:eventType" />
<any namespace="##other" processContents="lax"
<any namespace="##other" processContents="lax"
name="qnames" type="sca:listOfQNames" />
name="namespaces" type="sca:listOfAnyURIs" />
namespace="##other" processContents="lax" />
As you can see that
is an abstract element with only one substitution group member
(eventType.sca) but <body> is defined as a concrete
Hmmm. I'd actually argue the other way around. The use of
substitution group here is spurious. It is, quite simply the SCA
defined eventType filter of event types. It's overspecified to
allow eventType to be extended, because we don't *do* anything with
If you don't like the standard filter the spec defines, just take
advantage of the "<any namespace="##other" ..." declaration.
I propose we keep the . in body filter - if we need any
all they are
i) Update the schema so that
have an abstract element for the body filter, just like we do
for the eventType
filter. That would regularise the appearance of the .
character in the
ii) Capitalise the X and the
<body.XPath1> since it is usually referred to as XPath,
or xPath or Xpath.
I hate to spend so much time on naming, but to summarize:
a) Since it is defined as a global element "body.xpath1" should
include the word filter in its name. We either do that, or we turn
it into a local element. Same with "eventType.sca".
b) Using substitution groups here is spurious. In the other places
we've done that, there's been actual specification text about what
those extensions are. Here, we have no such purpose, so we
shouldn't do it. So "." shouldn't appear in the name, and we should
probably eliminate the substitution group for eventType.sca, and
just call it "eventTypeFilter".
c) I'm OK with moving the "XPath1" portion of the meaning to an
attribute, which could simplify this question by letting us call it
"bodyFilter", which has the benefit of being intuitive.
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
Action item 2010-12-07-3, ASSEMBLY-239
Thanks for the detailed explanation for your
comments inlined below.
On 12/20/2010 4:12 PM, Eric Johnson wrote:
In the call from two weeks back, I think we had
about 1/2 of the proposed resolution to ASSEMBLY-239.
We had an issue, however, with the proposed name change -
"body.xpath1" to "eventBodyFilter".
My action item - to come up with alternate name proposals.
Question: what to use as a separator? Choices: period
underscore ("_"), or camelCase? Why care?
Period used elsewhere to indicate a pattern of a base
Here such a substitution group is unnecessary, as the element
appears in a situation of explicit extensibility, where any
allowed, rather than elements that extend a specific construct.
the situation does not require any base set of information that
provided by the elements.
Underscore is not used elsewhere. Introducing it here might be
or at least distracting.
Conclusion: use camelCase pattern, which is used elsewhere.
Seems like a reasonable choice to me.
Question: What words do we need to include
name of the element? Options: "body", "xpath1"
(or variations), "event", "filter"
body xpath1 filter
body filter xpath1
filter body xpath1 (or, even more self-explanatory: "filter body
event body filter xpath1
As per discussions, I understand a strong desire from some
members of the
TC that "xpath1" appear in the name of the element, to
it from other possible languages for body filters.
Putting both "event" and "filter" in, for the moment
is mostly redundant, because "filter" only refers to events.
If we only choose one, then should it be "event" or "filter"?
Since "event" occurs in more places in the spec than "filter",
I conclude that "filter" in the name connotes a more precise
meaning than "event".
Based on the above, comment on "event" vs. "filter",
this suggests that we should change "eventType" to "typeFilter",
as it carries more meaning (admittedly, at the cost of an
Following the pattern of "typeFilter", then, it makes sense to
use some variation of "bodyFilter".
However, should it be "bodyFIlterXPath1", or "xpath1BodyFilter"?
Inventing some variations of "typeFilter", I came up with
"dynamicTypeFilter", "computedTypeFilter", and
The most natural place for the qualifier seems to be at the
front, so I
This element (and all filter expressions) can occur
as a child of the <filter> element. So both 'filter' and
are a little redundant. I have a very mild preference for
but other combinations (including Eric's recommendation) are
as my recommendation for the name of the element.
Unless stated otherwise
IBM United Kingdom Limited - Registered in England and Wales
Registered office: PO Box 41, North Harbour, Portsmouth,