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

[Peter Niblett <peter_niblett@uk.ibm.com>]

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.

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.

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

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

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

---

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