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.
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)
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.
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.
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.
-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
