OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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:
4D0FF0DC.9000407@tibco.com" type="cite"> 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.

4D0FF0DC.9000407@tibco.com" type="cite"> 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.
 
4D0FF0DC.9000407@tibco.com" type="cite"> as my recommendation for the name of the element.

-Eric.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]