Re: [sca-assembly] Issue 238 proposal v2

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Mike,

Thanks for your comments. My comments inlined below.

-Anish
--

On 11/19/2010 1:59 AM, Mike Edwards wrote:
>
> 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*
>

Appendix A.13 will go away and our filter eventType.sca would refer to 
the WS-RA EDL. Other than that nothing else should change.

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

Note that I have filed a comment with the WS-RA WG in W3C asking them to 
do two things:
a) Specify a recommended/best practice/whatever for the file extension. 
Something like .evd. If that happens then it could be treated the same 
way WSDL is treated wrt including it in a contribution and resolving it.
b) Consider something equivalent to schemaLocation/wsdlLocation. 
Currently, it requires WS-MEX to get the EDL.

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

I'm confused as to why this would be in the the definitions.xml. The EDL 
files that declare event types (similar to WSDLs that declare portTypes) 
could be located anywhere in the contribution or in a different 
contribution (subject to our import/export rules). In any case, since 
you have already filed an issue for this, we can discuss this during 
that issue resolution.

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

Do you want the fully qualified Java class to represent the event type 
or just the (mapping of) XML schema?
I had assumed (perhaps incorrectly) that folks who want to use Java 
classes for events would not bother to use this at all.
In any case, it is extensible because eventDefinition has <any> in it 
and eventTypeXSD has minOccurs="0".

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

I suppose we could do that, but I'll like to understand the usecases 
better. Wouldn't you just use JAXB to do the mapping?

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

We can't, as that is used by the filter. We'll have to come up with 
something different.

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

In the past we have agreed to stay away from defining standard metadata 
(or any serialization issues). I suppose we can change our minds and try 
and tackle this, although I am very wary of this. But in any case, I 
think this is a separate issue.

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