On the last call, I said I would look at
this issue and give my comments.
1. I agree completely with the part
of the issue that draws attention to the strange sentence "Context
Node: the root element of the document being searched based upon the subject.".
This was left over from an earlier draft, where we had metadata filters
as well as event body filters (i.e. two possible "subjects" for
the dialect), and the XPath filter dialects were described in a separate
part of the document. In the current working draft we have removed
metadata filters and the XPath dialect description this has been moved
inline into the filter description. This sentence got left in by accident
when this happened, and so should now be removed.
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 subject)
ii). The language used to express the
filter (the dialect)
iii). The filter expression itself.
It is helpful to retain the separation
of i) and ii), as it allows you to tell what the subject is, even
if you don't recognise the dialect. If we just had a flat name I could
define my own filter expression - say Peter_special_no_22 - and it
would not be possible to tell what kind of filter it is. Also if
you do a have a dialect used for more than one subject (e.g. XPath used
for both body and metadata) you only have to define its syntax and semantics
once. I actually
prefer a syntax where the dialect is expressed as an attribute (that's
what happens in WS-Notification and WS-Eventing), e.g.
<body dialect="xpath1">
A/B </body>
but I understand that the TC prefers
an approach where we include the dialect as part of the element name, so
I am ok with that,
3. This is what we have in the current
working draft
<filters>
<eventType.sca
qnames="list of xs:QName"? namespaces="list of xs:anyURI"?
/>*
<body.xpath1> xs:string
</body.xpath1>*
<any>*
</filters> ?
I agree with Anish that we don't need
the word "filter" in the filter QName, since these elements are
all children of the <filters> element.
4. I think it we should have a
consistent appearance for the two filter names (and any others we may introduce
in the future). Changing <body.xpath1> to <xpath1Body>
or <bodyXpath1> makes the body filter syntax and the eventTye filter
syntax inconsistent (in comparison with the consistent syntax we currently
have).
As I understand things, the issue now
is that we cannot use a . in the body name, since the element isn't defined
using a substitution group and everywhere else in SCA assembly a . implies
the substitution group. This is indeed the case.. here is the current schema
definition:
<element name="filters"
type="sca:Filter"/>
<complexType name="Filter">
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="sca:eventType" />
<element ref="sca:body.xpath1"
/>
</choice>
<any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<anyAttribute
namespace="##other" processContents="lax"/>
</complexType>
<element name="eventType"
abstract="true"/>
<element name="eventType.sca"
type=sca:EventType.sca"
substitutionGroup="eventType"/>
<complexType name="EventType.sca">
<sequence>
<any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<attribute
name="qnames" type="sca:listOfQNames" />
<attribute
name="namespaces" type="sca:listOfAnyURIs" />
<anyAttribute
namespace="##other" processContents="lax" />
</complexType>
<element name="body.xpath1"
type="string" />
As you can see that <eventType>
is an abstract element with only one substitution group member defined
(eventType.sca) but <body> is defined as a concrete element.
I propose we keep the . in body filter - if we need any changes at
all they are
i) Update the schema so that we
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
name
ii) Capitalise the X and the P, i.e.
<body.XPath1> since it is usually referred to as XPath, not xpath
or xPath or Xpath.
Regards
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
From:
Anish Karmarkar <>
To:
Date:
21/12/2010 07:50
Subject:
Re: [sca-assembly]
Action item 2010-12-07-3, ASSEMBLY-239
Thanks for the detailed explanation for your choice. Two
comments inlined below.
-Anish
--
On 12/20/2010 4:12 PM, Eric Johnson wrote:
In the call from two weeks back, I think we had agreement
about 1/2 of the proposed resolution to ASSEMBLY-239.
We had an issue, however, with the proposed name change - changing
"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 substitution group.
Here such a substitution group is unnecessary, as the element already
appears in a situation of explicit extensibility, where any element is
allowed, rather than elements that extend a specific construct. Further,
the situation does not require any base set of information that must be
provided by the elements.
Underscore is not used elsewhere. Introducing it here might be confusing
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 in the
name of the element? Options: "body", "xpath1"
(or variations), "event", "filter"
For example:
body xpath1
xpath1 filter
body xpath1 filter
body filter xpath1
filter body xpath1 (or, even more self-explanatory: "filter body with
xpath1"
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 distinguish
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 additional character).
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 "randomTypeFilter".
The most natural place for the qualifier seems to be at the front, so I
conclude:
"xpath1BodyFilter"
This element (and all filter expressions) can occur only
as a child of the <filter> element. So both 'filter' and 'event'
are a little redundant. I have a very mild preference for 'bodyXpath1',
but other combinations (including Eric's recommendation) are fine too.
as my recommendation for the name of the element.
-Eric.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
