Replies inlined below.
-Anish
--
On 11/24/2010 3:20 AM, Mike Edwards wrote:
OFF3599573.069C076E-ON802577E5.003B5E3B-802577E5.003DE269@uk.ibm.com"
type="cite">
Anish,
I learned some more - but that
leads
to some more comments ;-)
Comments inline as <mje>...</mje>
Yours, Mike
|
|
Dr
Mike Edwards
|
Mail Point
146, Hursley
Park
|
|
STSM
|
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
|
|
|
|
|
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.
<mje>
I expected the
filter to
simply refer to an event type QName - would this really change
if
we use WS-RA EDL ?
</mje>
<ask> No, this would stay the same </ask>
OFF3599573.069C076E-ON802577E5.003B5E3B-802577E5.003DE269@uk.ibm.com"
type="cite">
> *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.
<mje>
OK, what I learned
from
this comment is that you expect the event definitions to be
present in some
new separate
file, ideally with a fixed filename extension - something
similar to a WSDL.
My idea had been
to include
the same declarational material in definitions.xml files.
I am OK with the
idea of
using simple SCA resolution mechanisms to get the
declarations
loaded
</mje>
<ask> Yes, that is how I see things working together.
Apologies, if I didn't make it clear in my earlier comments. The
EDLs should be structured to be independent of SCA artifacts.
Especially if we start using the EDL defined by WS-RA </ask>
OFF3599573.069C076E-ON802577E5.003B5E3B-802577E5.003DE269@uk.ibm.com"
type="cite">
b) Consider something equivalent to
schemaLocation/wsdlLocation.
Currently, it requires WS-MEX to get the EDL.
<mje>
The mention of a
schemaLocation
style of mechanism has me reaching for the garlic
and a nice big
stake -
basically no way do I want to see another one of these being
invented.
As for WS-MEX,
that is
completely unacceptable as far as structuring an SCA
application...
</mje>
<ask> I don't want to see WS-MEX either. Although I'm told
that WS-MEX has ways to make things simple, but I don't know if that
would still require conformance to all of WS-MEX.
WRT, killing the vampire (or Zoombies, as Eric points out): I would
like to understand the pain point wrt schemaLocation/wsdlLocation
</ask>
OFF3599573.069C076E-ON802577E5.003B5E3B-802577E5.003DE269@uk.ibm.com"
type="cite">
>
> *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>
I get the idea -
it just
that it is yet another file type that we must track...
</mje>
> *</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".
<mje>
I take the view
that this
is like using a Java interface rather than a WSDL.
If you build your
stuff
in Java, why would you be forced to create an XSD mapping?
So for me there
should
be an eventTypeJava, which declares events in terms of Java
artifacts. Those
SHOULD map to XML/XSD, but the developer should not be forced
to
create the mapping
manually.
Current
extensibility is
not suitable for this concept.
</mje>
<ask>
This obviously is a much bigger issue and certainly a separate one.
But something that needs to be discussed. This is how I envisioned
things would work:
For the assembly part, what is important is the filter -- that is
the only place where event type shows up (at design time).
We have a filter <eventType.sca> -- this expresses things in
terms of QNames and is associated with XSD-based EDLs (hopefully
WS-RA's EDL). If there is a need to use Java-based event types, then
I imagine that the filter would be something like
<eventType.java> which points to one or more Java classes.
There really won't be a need for a separate EDL (similar to WS-RA's
EDL).
If we wanted to treat this similar to the way we treat WSDL and Java
interfaces (mapability requirement), we can define how the mapping
takes place (or rather the spec for eventType.java) would specify
that.
IOW, The EDL (<eventDefinitions>/<eventTypeXSD>) won't
be used with Java-based systems, but would be mappable to one.
</ask>
OFF3599573.069C076E-ON802577E5.003B5E3B-802577E5.003DE269@uk.ibm.com"
type="cite">
> *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?
<mje>
JAXB may be used
to map
at runtime, but it ain't the way the developer would work
</mje>
> *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.
<mje>
It may be a
separate issue,
but if we are going to concern ourselves with interop - and
I think that we
should
- then we can't avoid discussing the issue of how metadata is
transmitted
</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
|