My counter-proposal:
Section 3.1.4 (Component type producer):
line 852: drop reference to "See section Use of <eventType> on
Producer".
Section 3.1.4.1: Gets the current contents of 9.2.1.1
Section 4.5 (Component producer).
line 1587: replace reference to refer to new location at 3.1.4.1
Section 5.6 (Composite producer).
line 2820: delete reference to Use of <eventType> on Producer.
Section 5.6.1: Gets the current contents of 9.2.1.2
Section 9.1:
Snippet 9-1 (the pseudo-schema):
Change "eventType.sca" to "eventTypeSet". Change "body.xpath1" to
"matchBodyXPath1".
Section 9.2:
p. 105, line 4176: Replace occurrence of "eventType.sca" with
"eventTypeSet".
Section 9.2.1:
-- deleted --
Section 9.2.1.1: (moves to become 3.1.4.1)
(NOTE: This section has a reference to @typeNames that is
undefined!)
Section 9.2.1.2 moves to become 5.6.1)
Section 9.2.2
Replace references to "eventType.sca" with "eventTypeSet".
Section 9.3:
line 4260: replace "xpath1" with "XPath 1"
Section 9.3.1:
line 4262, 4263: replace "body.xpath1" with "matchBodyXPath1"
Change the definition of Context Node as Peter describes below.
Appendix A.2
line 5944-5: change to (makes these two definitions local!)
<element name="eventTypeSet" type="sca:eventType.sca"/>
<element name="matchBodyXPath1" type="xsd:string" />
line 5968: delete (definition of body.xpath1)
One minor note about Peter's items below - he appears to have
different line numbers for schema changes than the WD 03 PDF.
-Eric.
On 2/7/11 5:35 AM, Peter Niblett wrote:
I have an action item
to propose changes
to the spec, assuming we took my preferred answers to these
questions.
1. The pseudo schema shown in
snippet
9.1 changes from this:
<filters>
<eventType.sca
qnames="list
of xs:QName"? namespaces="list of xs:anyURI"? />*
<body.xpath1>
xs:string
</body.xpath1>*
<any>*
</filters> ?
to this
<filters>
<eventTypes.sca
qnames="list of xs:QName"? namespaces="list of xs:anyURI"?
/>*
<body.XPath1>
xs:string
</body.XPath1>*
<any>*
</filters> ?
a) eventType has become
eventTypes,
since it can specify more than one type.
b) xpath1 has become XPath1,
since
that's the received way of spelling it.
2. Change eventType to
eventTypes everywhere
that it appears in section 9.2 (there are many places)
3. Change body.xpath1 to
body.XPath1
in section 9.3
4. In section 9.3.1 change the
definition
of Context Node from
· Context
Node: the root element of the document being searched based
upon the subject.
In this case (the Business Data Subject) it is the root
element of the
event business data.
to
· Context
Node: the root element of the business data portion of the
event.
(the old words were left over
from a
much earlier version and should have been deleted)
5. Change the Filter type
definition
in the sca-core.xsd (line 5959) from
<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>
to
<complexType
name="Filter">
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="sca:eventTypes"
/>
<element ref="sca:body" />
</choice>
<any namespace="##other" processContents="lax"
minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<anyAttribute
namespace="##other" processContents="lax"/>
</complexType>
and change lines 5971 to 5986
(the end
of the core schema) from
<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" />
to
<element
name="eventTypes"
abstract="true"/>
<element
name="eventTypes.sca"
type=sca:EventTypes.sca"
substitutionGroup="eventTypes"/>
<complexType
name="EventTypes.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"
abstract="true"/>
<element
name="body.XPath1"
type="string"
substitutionGroup="body"/>
a) eventType has become
eventTypes
b) .xpath1 has become .XPath1
c) substitution groups used
for body
as well as for eventTypes
6. (optional) Move the
declaration of
<body.XPath1>, <eventTypes.sca> and the
EventTypes.sca type
definition into a new sca-filters.xsd, for consistency with
other substitution
element declarations.
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
-----
Forwarded by Peter
Niblett/UK/IBM on 07/02/2011 11:50 -----
From:
Peter Niblett/UK/IBM
To:
Eric Johnson
<>
Cc:
Anish Karmarkar
<>,
Date:
18/01/2011 15:55
Subject:
Re: [sca-assembly]
Action item 2010-12-07-3, ASSEMBLY-239
Hi Eric
I think we have identified our
points
of difference, and we should see what the others think. Here's
a
quick summary of the main two , using the numbers from my
previous email.
2. Should we declare the two
filters
that we have (EventType and Body) using substitution groups or
not?
Peter. Yes,
it provides an extensibility mechanism to allow other filters to
be added
without the need to change the core schema
Eric. No
- they don't satisfy any of the conditions that apply to other
places where
substitution groups are needed:
some base structure that was actually
required to be shared
(not true in this case)
more than one substitution actually defined
by the SCA
family of specs (not true in this case)
a place where a single instance of an element
was appropriate
(implementation.????), but vendor extensibility mattered
(not true in this
case)
Also
the chances of adding further filters without changing the core
schema
are ~ 0%.
4. Is it ok to use "." period
in element names if there isn't a substitution group?
Peter. Yes,
it's a useful separator that distinguishes the part of the name
that represents
the concept (a body filter or an event type filter) from the
language used
to express it. It makes the SCDL clearer. Not many SCDL readers
will look
at the schema and know whether we are using substitution groups
or not
- and not all of them will understand what substitution groups
are anyway.
Eric. No,
we have a convention that "." implies a substitution group, and
we should stick to that.
Regards
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
From:
Eric Johnson
<>
To:
Peter
Niblett/UK/IBM@IBMGB
Cc:
Anish Karmarkar
<>,
Date:
17/01/2011 22:48
Subject:
Re: [sca-assembly]
Action item 2010-12-07-3, ASSEMBLY-239
Hi Peter,
On 1/13/11 7:01 AM, Peter Niblett wrote:
Thanks Eric
I have put comment in line, but I'll summarise all the things
that have
come up in this discussion.. Some of these are going a bit
beyond the original
scope of this issue.
1. Remove the sentence that says "Context Node: the root
element
of the document being searched based upon the subject.". This
is agreed.
2. Regardless of what they
are
called, how should we declare the two SCA-defined elements
that can be
appear in <filters> (we currently have one called
eventType and one
called body)
a) As abstract substitution
group head
elements, with separate global elements to be substituted in ?
b) As concrete global
elements, referenced
by the Filter complex type ?
c) As elements defined locally
in the
Filter complex type ?
At the moment we use approach
a) for
eventType and b) for body, and there seems to be no reason to
handle them
differently.
I think you favour c) for both. I prefer a) for both, since I
think
there's some value in being able to add SCA-namespaced filters
without
having to change the sca core xsd file. I don't see a lot
of value in b), unless there's some established SCDL
convention that would
encourage the use of global elements.
As I said below, I think that using substitution groups here
doesn't satisfy
any of the reasons that they've been used elsewhere in the
specs.
If you have a concern that we've not captured the XPath2 use
case, then
by all means, let's add that element definition. I don't
think this
requires a substitution group.
A subsidiary point here is that, if we use substitution groups
then it
would seem appropriate to move the substitution element
declarations (i.e
the concrete things that get substituted in) out of the core
sca xsd file.
At the moment all the substitution elements are outside the
core schema
with the exception of eventType.sca
3. Do we envisage adding additional SCA-namespaced filters,
e.g.
event Types specified by Java classes, or body filters
specified in XPath
2.0? This isn't part of this issue, but has a bearing on
point 2.
Even if we do, what are the chances that we'll do so without
*any* other
changes to the core schema. My guess ~ 0%.
4. Is it ok to use "." period in element names in cases
where there is no substitution group in the schema ? At the
moment
all occurrences of "." correspond to the use of substitution
groups, except for <body.filter>. This question would
become irrelevant
if we were to choose to use substitution groups for body
filters (I think
everyone agrees that it's ok to use "." in that case). You
feel strongly that "." should only be used when there's a
substitution
group. I think we should be able to use "." if it makes the
SCDL
clearer - not many SCDL readers will be looking at the
schema.
5. The element name <eventType> is misleading, since it
can point
at multiple event types. I agree.
6. The element name <body.xpath1> has the following
issues
i) It contains a "." (see point 4)
ii) The name is too generic to be used as a
global element name
iii) xpath should be XPath
It seems to me we have four outcomes, depending on the answers
to 2 and
4
A. Use Substitution Groups for both event type and body
filters
This means we would need to use "." in the names (as today)
but
we should generalize the body filter name to be
<bodyConstraint.XPath1>.
We should also move the substitution element declarations out
of the core
sca schema.
B. Use local element declarations for the filters, and decide
that it's
ok to use ".". It would then be ok to call the body filter
<body.XPath1>
C. Use global element declarations for the filters, and decide
that it's
ok to use ".". As in A we would then change the body filter
name to be <bodyConstraint.XPath1>.
D. Use local of global declarations and decide that it's not
ok to use
".". I think it would be better to have the XPath1 qualifier
at the end, so the element name would be
<bodyConstraintXPath1>.
Works for me, but we should also make "elementType" a local
element,
and fix its name, as I suggested below, to "eventTypeSet".
-Eric.
Regards
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
From: Eric
Johnson <>
To: Peter
Niblett/UK/IBM@IBMGB
Cc: Anish
Karmarkar <>,
Date: 12/01/2011
22:00
Subject: Re:
[sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
Hi Peter,
Thanks for clarifying. I attempt to respond interleaved below
to
the points I think need further discussion.
On 1/12/11 6:27 AM, Peter Niblett wrote:
Hi Eric
2. I still think we should use a consistent syntax for both the
Body and
the EventType filters, so if the acceptability of the . is tied
to the
presence of the substitution group in the schema we should ask
why there's
a substitution group for eventType and not one for body filters.
At
the moment we only define one possible dialect for eventType and
one for
body, and it's not clear why there should be this distinction..
The reason that there is a substitution group for the EventType
is that
we wanted to allow the SCA defined filters to be extended to
support multiple
type systems for events. The <anyAttribute
namespace="##other" processContents="lax" />
mechanism only allows
extension
by elements from a different namespace and is intended for
vendor-specific
things. So the only other way to extend the SCA spec in the
future to have
- for example - sca:eventType.java or
sca:eventType.wsEventDescriptions
is to change the definition of the Filter complex type to add
these extra
things into the <choice>. The precedent set in other parts
of SCDL
is to use substitution groups so that these additional things
can be contributed
to the SCA namespace without having to modify the definitions of
the types
that have already been defined. It seems to me that if you buy
this
argument, the case for doing the same thing for body (e.g. add
XPath 2
support) is strong.
Yeah, I don't buy it. In some hypothetical future version of
SCA
(1.3, 2.0?), we somehow expect to maintain a fully backwards
compatible
XML Schema? (Are you planning on working on SCA for another
five
to ten years?)
And even if we did maintain compatibility, what's the point?
The
semantics of additional type systems supported by the core spec
mean that
even if the schema is valid, no 1.2-level clients will support
it.
To me, this substitution group looks like future-proofing that
won't even
work.
<pn> The thing that bothers me most here is the need for
XPath 2
filter support. Including XPath 2 is a separate issue, but I
would like
to see us having a way in which it can be plugged in without
having to
redo the Assembly spec and the sca-core.xsd - and without
having
to use the xs:any which at present is only suitable for
vendor-specific
extensions. I don't hold a particular brief for the use of
substitution
groups, so I will see if anyone else wants to comment on this
but I note
that it is a mechanism that is used elsewhere..</pn>
As to where we've used substitution groups elsewhere, we've done
so when
it made sense for a number of reasons:
some base structure that was actually
required to be shared
(not true in this case)
more than one substitution actually defined
by the SCA
family of specs (not true in this case)
a place where a single instance of an element
was appropriate
(implementation.????), but vendor extensibility mattered
(not true in this
case)
<pn> We
do have substitution groups where the head element doesn't
define a structure
(e.g. wireFormat and operationSelector). On the second point, I
concede
that there's only one eventType and one body dialect defined at
present
- but as I said I am thinking about XPath 2.0 here which would
motivate
a second body dialect. I have also heard discussion of defining
event types
in Java which would motivate a second event type dialect. . Your
third
point is really that we already have an extensibility mechanism.
I would
claim that that is intended to allow third parties to introduce
different
filter subjects and that there is some value in having third
parties indicate
that the new filter that they are introducing is in fact a kind
of eventType
filter or a kind of bodyFilter. I agree that this could be done
with a
naming convention though.
There is another aspect of the existing substitution groups, and
that is
that the substitution elements are declared in their own xsd
files, and
not in the sca-core.xsd file. This emphasises their role as
plugin extensions
to the core and allows them to be added with changing the core
schema -
indeed in some cases the elements are described in a different
spec, not
the assembly spec at all. It does seem a bit strange that
eventType.sca
is declared in the core xsd. </pn>
3. I understand your logic about local versus global elements
and the need
for meaningful names for global elements because you can
encounter them
independently from their containing element(s). The reason these
are global
elements is of course tied in to the substitution group
argument.
Actually <eventType> also needs to be a global element
because it
is used in other contexts (e.g. on a Producer) as an event type
identifier.
It's only when it appears as a child of <filters> that it
is used
as a filter, so it is inappropriate to change it to be
<eventTypeFilter>.
This suggests a pattern where the GED name should reflect what
the parameter
means (in this case it is a type identifier but we are using a
well-accepted
convention of dropping the word Identifier) and the containing
context
dictates what it is used for.
To me, you've underscored that we're overloading the use of a
global element.
Perhaps we should simply not do that? We've got a perfectly
good XML Schema type defined here, so let's define a local
definition (gasp!)
that references the existing type.
<pn>I guess it's a matter of taste whether you indicate a
common
semantic by using the same type or the same element name. I
notice that
there seems to be a lot of use of refs and GEDs in the rest of
the core
schema, I assumed that was a stylistic choice made when we
started on the
core schema,, but maybe it's just because a lot of the elements
are substitution
heads and so have to be global. </pn>
Either that, or the "eventType" element should be changed to
"eventTypeSet", as what it is properly doing is defining not
a single type, but a set of event types. With that name, I
think
it fits in either context.
<pn>Good point. Its name should reflect the fact that it
can point
at a plurality of event types. How about just calling it
eventTypes
?</pn>
Back to the quest for a more meaningful name for
<body.xxx>.
Putting Filter into the name is repetitious and also restricts
the element
to this particular use (ok, I know that that's the only use we
currently
have for it). How about something that suggests what it actually
is - a
constraint on the contents of the event body? Would
<bodyConstraint.xxx>
work, or would <dataConstraint.xxx> be better?
Given that I don't think the substitution group is appropriate,
I'm still
very much against the "." (period). "bodyConstraintXPath1"
works for me, but I think "xpath1BodyConstraint" reads more
naturally.
<pn>It's only an SCA convention that associates the "."
with a substitution group. You could say that our convention is
that "."
is associated with an extension point - and it just happens that
all the
ones defined so far have been backed up with substitution groups
in the
schema. I think more people are going to see the element name
than are
going to look at the schema (and the set of people who
understand substitution
groups is going to be smaller still), so if it makes things
clearer to
use a "." in the name, we shouldn't get too hung up about the
substitution group point. Do you have a dislike of "." for other
reasons?
I prefer the XPath1 going at the end, because that's where it
goes in the
names of the other elements that have qualifiers (i.e. the ones
with a
"." in like implementation.xxx that we aren't debating)
</pn>
-Eric.
Regards
Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)
From: Eric
Johnson <>
To: Peter
Niblett/UK/IBM@IBMGB
Cc: Anish
Karmarkar <>,
Date: 11/01/2011
18:56
Subject: Re:
[sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
A response:
On 1/11/11 2:08 AM, Peter Niblett wrote:
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,
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
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.
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
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.
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 that capability.
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 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
Why?
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.
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.
-Eric.
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
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
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
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
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
