[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Fw: [sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
I prefer Peter's - body.<language> is consistent with other specific (language)bindings in sca.
> -----Original Message-----
> From: Anish Karmarkar
> Sent: 05 April 2011 20:53
> To: sca-assembly@lists.oasis-open.org
> Subject: Re: Fw: [sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
>
> On 4/5/2011 10:12 AM, Peter Niblett wrote:
> > Simplified version of the two options, leaving out some of the details.
> > For more background, please refer back along the email thread.
> >
> > 0. Current spec version (for reference)
> >
> > * The two filter element names are <eventType.sca> and <body.xpath1>
> > * The event type filter is represented in the schema as an abstract
> > Global Element called <eventType> heading a substitution group,
> > along with a a concrete <eventType.sca> Global Element Declaration.
> > * The body filter is represented in the schema as a concrete Global
> > Element Declaration called <body.xpath1>. There is no substitution
> > group or abstract element declaration.
> >
> > 1. Eric's proposal
> >
> > * The filter elements become <eventTypeSet> and <matchBodyXPath1>
> > * The filter elements are declared in the schema as local elements
> > contained in the Filters complex type definition, so in effect
> > they become
> >
> > filters/eventTypeSet and
> > filters/matchBodyXPath1
> > * The ProducerContract complex type is changed so that the reference
> > to the eventType abstract element is replaced with a new local
> > element called eventTypeSet
> >
> >
> > 2. Peter's proposal
> >
> > * The filter elements become <eventTypes.sca> and <bodyXPath1>
> > (minor updates to the spelling)
>
> I think you meant body.XPath1 (with the ".")
>
> -Anish
> --
>
> > * The schema representation of <eventTypes> stays the same as today
> > (except for the addition of the extra s)
> > * In the schema we introduce an abstract <body> element heading a
> > substitution group, with a concrete <body.XPath1> element declared
> > as a substitution element for it. This brings it into line with
> > <eventTypes>.
> >
> >
> > Peter Niblett
> > IBM Senior Technical Staff Member
> > Member of the IBM Academy of Technology
> > +44 1962 815055
> > +44 7825 657662 (mobile)
> >
> >
> >
> >
> > From: Peter Niblett/UK/IBM@IBMGB
> > To: Eric Johnson <eric@tibco.com>
> > Cc: sca-assembly@lists.oasis-open.org
> > Date: 08/02/2011 11:30
> > Subject: Re: Fw: [sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
> > ------------------------------------------------------------------------
> >
> >
> >
> > Eric's proposal includes moving sections 9.2.1.1 to become a new 3.1.4.1
> > and 9.2.1.2 to become a new 5.6.1. I don't have this in my proposal,
> > since it isn't directly relevant to the subject of this issue.
> >
> > I think the reason for doing this is that when you put this element (
> > <eventTypes> or <eventTypeSet> whichever we decide to call it) on a
> > Producer it isn't acting as a filter. So strictly speaking sections
> > 9.2.1.1 and 9.2.1.2. don't belong in chapter 9, since this chapter is
> > about filters. The problem I can see with this is that the material in
> > these sections refers to the structure of the element which is discussed
> > in the intro section of 9.2 (which is still in the filters chapter) and
> > in order to understand these sections you are going to have to flip
> > forward to 9.2 anyway. To do this thoroughly, we should move the
> > <eventTypes> or <eventTypeSet> discussion and the current 9.2.1.1 and
> > 9.2.1.2 to chapter 8. Then section 9.2 can refer back to chapter 8 when
> > it describes the use of <eventTypes> or <eventTypeSet> as a filter, and
> > the 3.1.4 and 5.6 references can refer forward to it.
> >
> > My proposal should also have noted that the change of name of
> > <eventType> to <eventTypes> also affects 3.1.4 and 5.6 and the schema at
> > line 5598 (I am using PDF line numbers from the WD03 draft at [1]).
> >
> > So in case anyone is confused by all this, the material differences
> > between the proposals (apart from moving sections of the spec around) are
> >
> > 1. The element names:
> >
> > <eventTypeSet> vs <eventTypes.sca>
> > <matchBodyXPath1> vs <body.XPath1>
> >
> > 2. The schema representation
> >
> > In Eric's proposal, the two elements are declared as local elements in
> > the Filters type definition, so in effect they become
> >
> > filters/eventTypeSet and
> > filters/matchBodyXPath1
> >
> > In my proposal <eventTypes> and <body> are both abstract elements
> > heading substitution groups, with concrete <eventTypes.sca> and
> > <body.XPath1> elements declared as substitution elements for them.
> >
> > Eric doesn't mention this, but his proposal will I think also need a
> > change to the schema at 5568 to declare another local element (also
> > called eventTypeSet ? ) for the Producer to use.
> >
> > [1]
> > _http://www.oasis-open.org/apps/org/workgroup/sca-
> assembly/download.php/40972/sca-assembly-1.2-spec-wd03_clean.doc_
> >
> >
> > 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: sca-assembly@lists.oasis-open.org
> > Date: 08/02/2011 01:00
> > Subject: Re: Fw: [sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
> > ------------------------------------------------------------------------
> >
> >
> >
> > 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>
> > <eventType*s*.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 _<eric@tibco.com>_ <mailto:eric@tibco.com>
> > Cc: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_
> > <mailto:Anish.Karmarkar@oracle.com>, _sca-assembly@lists.oasis-open.org_
> > <mailto:sca-assembly@lists.oasis-open.org>
> > 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 _<eric@tibco.com>_ <mailto:eric@tibco.com>
> > To: Peter Niblett/UK/IBM@IBMGB
> > Cc: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_
> > <mailto:Anish.Karmarkar@oracle.com>, _sca-assembly@lists.oasis-open.org_
> > <mailto:sca-assembly@lists.oasis-open.org>
> > 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 _<eric@tibco.com>_ <mailto:eric@tibco.com>
> > To: Peter Niblett/UK/IBM@IBMGB
> > Cc: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_
> > <mailto:Anish.Karmarkar@oracle.com>, _sca-assembly@lists.oasis-open.org_
> > <mailto: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>_ <mailto:eric@tibco.com>
> > To: Peter Niblett/UK/IBM@IBMGB
> > Cc: Anish Karmarkar _<Anish.Karmarkar@oracle.com>_
> > <mailto:Anish.Karmarkar@oracle.com>, _sca-assembly@lists.oasis-open.org_
> > <mailto: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>_
> > <mailto:Anish.Karmarkar@oracle.com>
> > To: _sca-assembly@lists.oasis-open.org_
> > <mailto: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_
> > <http://www.osoa.org/jira/browse/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/
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> > /
> > /
> >
> > /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/
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]