sca-assembly message

Subject: Re: [sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239

From: Peter Niblett <peter_niblett@uk.ibm.com>
To: Eric Johnson <eric@tibco.com>
Date: Wed, 12 Jan 2011 14:27:50 +0000

Hi Eric

Thank you for this.. it's probably easier if I call out my replies to your response rather than trying to interleave them

1. I raised the dialect attribute question on the Jan 4th call, but several people - including I think Danny - said they preferred the approach of embedding the dialect name in the element QName. The reasons suggested were

i) When using an XPath expression to retrieve the filter from the SCDL, it's tidier if you can use expressions like //filterSubject.filterDialect rather than //filterSubject[@dialect = "filterDialect"] (where filterSubject, filterDialect are the subject and dialect in question.

ii) We should stick to using either elements or attributes, and not attempt to mix the two.

so if we wanted to use attributes we should go all the way and do <filter subject="body" dialect ="xpath1">

iii) It's more convenient for implementations (such as Tuscany) to use the filter QName as their extensibility mechanism. What this is in effect saying is that they don't need the complexity of the two levels of extensibility (subject and dialect) and are happy with just a single combined subject/dialect mechanism.

Had I been quicker on my feet I might have pointed out that the attribute approach makes it easier to use complex URIs to specify the dialect (which is what these other specs do), but I doubt that would have won people over.

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.

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.

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?

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 <eric@tibco.com>
To: Peter Niblett/UK/IBM@IBMGB
Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, sca-assembly@lists.oasis-open.org
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.

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:

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 <Anish.Karmarkar@oracle.com>
To: sca-assembly@lists.oasis-open.org
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

Follow-Ups:
- Re: [sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
  - From: Eric Johnson <eric@tibco.com>

References:
- Re: [sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
  - From: Peter Niblett <peter_niblett@uk.ibm.com>
- Re: [sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
  - From: Eric Johnson <eric@tibco.com>