[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [sca-assembly] Action item 2010-12-07-3, ASSEMBLY-239
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>
<eventTypes.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>
Cc:
Anish Karmarkar <Anish.Karmarkar@oracle.com>,
sca-assembly@lists.oasis-open.org
Date:
18/01/2011 15:55
Subject:
Re: [sca-assembly]
Action item 2010-12-07-3, ASSEMBLY-239
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>
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
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
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]