Re: [sca-assembly] Issue 238 proposal v2

[Mike Edwards <mike_edwards@uk.ibm.com>]

Anish,

Thanks for working on this.

Comments inline as  <mje>..</mje>

Yours, Mike

Dr Mike Edwards		Mail Point 146, Hursley Park
Technical Strategist		Winchester, Hants SO21 2JN
SCA & Services Standards		United Kingdom
Co-Chair OASIS SCA Assembly TC
IBM Software Group
Phone:	+44-1962 818014
Mobile:	+44-7802-467431 (274097)
e-mail:	mike_edwards@uk.ibm.com

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date:	18/11/2010 23:51
Subject:	[sca-assembly] Issue 238 proposal v2

---

I have uploaded v2 of the 238 proposal at:

http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/40315/sca-assembly-1.2-spec-wd01-issue238v2.pdf
and
http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/40314/sca-assembly-1.2-spec-wd01-issue238v2.doc

If you don't want to be confused with spurious diffs from crossref 
updates please look at the PDF and not the Word doc. The PDF version 
contains pages only from sections 8, 9 and Appendix A. These three 
sections are the only ones that are relevant to the proposal.


If you are curious as to where the other spurious changes in v1 came from:
All of them are from cross-reference updates. 4 of those occurred 
because they used the wrong cross-reference (a cut-and-paste error that
is also present in WD01). I fixed those 4 cases. The other cases, I 
tried to fix them, but Word keeps updating the auto-generated 
cross-reference text (with identical text) even after I accept the new
changes -- I can't figure out why Word keeps doing that. I tried using
OOo, but that made the problem even worse. The diffs showing up in the
example Snippet references weren't worth fixing, since 1.2-wd01 is a 
branch of 1.1-cd04 and at some point we'll have to migrate to 1.1-cd06
(or later).

<mje>
One thing to consider seriously
for the 1.2 version of the specs is whether to do a
complete migration to OpenOffice
from Word format.  I note that most of the newer
spec documents are in OO
format.

The time to make such a
significant change is at the point where we rebase 1.2 on
the final 1.1 spec.

I'd appreciate knowing
everyone's view on this. I personally find OO easier to handle
today than Word,  but
I realize that may not be the general view.
</mje>

In any case, till we migrate to the latest version of 1.2, the best 
solution for now I think is to look at sections 8/9 and Appendix A as 
those are the only sections relevant to this proposal.

+1


Here is the explanation for the proposal (the actual text changes are 
small, but below is the rationale for those changes):

There are three syntactic uses of eventType (or some various of it):
(a) in the EDL, (b) in the event instance/message, (c) in the filter

(a) The EDL defines a QName for the event type and points to the 
associated XSD. If you are not using XSD, there will some other way to
define the event type (the example that has been discussed in the past
is a fully qualified Java class name). This is the EDL eventtype. In the
proposal it is called sca:eventTypeXSD. If we use the EDL defined by W3C
WS-RA then we won't be doing any work wrt this.

<mje>
One question I ask is what
the spec would look like if we use the WS-RA EDL

One thing in common with
our current spec is that it is not clear to me where the 
EDL XML is placed within
Contributions.  The current spec is silent on this - and that
is not good.  I'd
like to fix that as part of the resolution of this issue.

My proposal is that, as
with Intent definitions, it should be possible for them to be
declared within a definitions.xml
document.  This DOES NOT rule out the potential
for them to be declared
elsewhere (such as a repository), but it since repositories
are out of scope of the
spec, I think it is necessary to have one normative way of
declaring event types,
even if products provide other more sophisticated means.
</mje>

<mje>
My second problem with
the current EDL is that it is NOT extensible.  Look at the
EventDefinitions declaration:

    <complexType
name="EventDefinitions" >
       <complexContent>
       
  <extension base="sca:CommonExtensionBase">
       
     <sequence>
       
        <element ref="sca:eventTypeXSD"
minOccurs="0"  maxOccurs="unbounded" />
       
        <any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
       
     </sequence>
       
     <attribute name="targetNamespace" type="anyURI"
use="required" />
       
     <anyAttribute namespace="##other" processContents="lax"
/>
       
  </extension>
       </complexContent>
    </complexType>

which points at:

    <element
name="eventTypeXSD" type="sca:EventTypeXSD" />
    <complexType
name="EventTypeXSD" >


I note that event types
can thus ONLY be declared as sca:eventTypeXSD.  If (say) we wanted
to declare
an eventType in terms of
some Java Class for example, then there is no way to do that.  

To do that would require
defining eventTypes in terms of some base (abstract) type which is the
head of
a substitution group, similar
to the way we've done extensibility elsewhere.

If we don't do extensibility
then we might just as well call this type "eventType"...

</mje>

b) the event instance *may* contain metadata for event type (such as a
header). For example, there may be a eventType header. Note the spec is
silent on this.

<mje>
I'm not sure that we can
live with this if we start to concern ourselves with interop.

For example, if we happen
to send events over either Web services or via JMS,
can the spec be silent
about a) whether "EventType" is transmitted  and b) where
it is transmitted?  My
view is that we cannot.
</mje>

c) The filters on a consumer/channel may specify an filter based on 
event types. This is the one thing that is specified by our spec and 
will persist even if we adopt WSRA's EDL. The filter schema consists of
two parts:

eventType -- an abstract element (substitution group head)
eventType.sca -- concrete element that uses our EDL (or will point to 
WSRA's EDL, if adopted) and is part of the substitution group. This 
requires that the definition of the event type must use XML schema as 
defined by our spec (currently) or WS-RA, if adopted.

One can extend this by creating eventType.java or 
eventType.myFavoriteExtension

It is important to note that the eventTypeXSD syntactic element defined
by the EDL (in (a) above), cannot be used for filtering. The filtering
element points to one or more QNames/namespaces used by the EDL. The 
structure of the elements is very different. This is the main error 
pointed out by issue 238 wrt 1.2-wd01 that this proposal fixes.

An example:

(a) EDL --

<eventDefinitions targetNamespace="http://example.org/edl"
...>
   <eventTypeXSD name="PrinterEvent" element="foo:PrinterData"/>
</eventDefinitions>

(b) Event instance, if it used XML (made up example) --

<foo:PrinterData ...>
   <foo:header>
     <foo:eventType>...</foo:eventType>
     ...
   </foo:header>
   <foo:body>
     ...
   </foo:body>
</foo:PrinterData>

(c) filter on the event type PrinterEvent defined by the EDL above --

<filters xmlns:ex="http://example.org/edl"
...>
   <eventType.sca qnames="ex:PrinterEvent" />
</filters>


-Anish
--


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

---

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