[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
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/
>
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]