RE: WS-Eventing issue 6424 proposal

I'd like to explore points 'c' and '4' a little more.
One of the reasons I think Wu's proposal works for me (meaning it doesn't 
send me screaming from the room) is because it has so few changes to the 
specs. If we fully define the infoset properties in the new infoset 
sections then those sections will grow quite a bit.  I was hoping to keep 
those sections small and just show the infoset schema thingy.  Then in the 
normal part of the spec where we define what each XML element means, we 
can link to each infoset property (like Wu does) and fully define it. This 
also allows us to avoid having two pieces of descriptive text (one in the 
infoset section, and one in the xml section) that basically says the same 
thing.  Also, didn't we decide that the XML version of the properties 
would be the authoritative version?  Basically, points c+4 worry me w.r.t. 
bloat.

The other points make sense.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com



Geoff Bullen <Geoff.Bullen@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org
02/24/2009 10:39 AM

To
"Chou, Wu (Wu)" <wuchou@avaya.com>, Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, 
"public-ws-resource-access-request@w3.org" 
<public-ws-resource-access-request@w3.org>
Subject
RE: WS-Eventing issue 6424 proposal






Wu,
 
If we are going to use your example of Infoset usage as a template for all 
specifications, then we have the following suggestions:
 
1)
Suggest property template wording to go from:
This optional element conveys the [endto endpoint] property.
To be:
This OPTIONAL element (of type wsa:EndpointReferenceType) provides the 
value for the [endto endpoint]  property.
This involves changing the XML definition to match as well (it is 
currently ?endpoint-reference?).  Mostly the XML definitions are correct.
 
2)
There is no need to define standard addressing headers again here in the 
Eventing spec (like wsa:To).  Thus [event source] is not required.
 
3)
Infoset property names should be the same as the associated XML element 
names.  Thus it should be: [endto] not [endto endpoint].
 
4)
There should be a description associated with each Infoset property 
definition.
 
This suggests a few basic principles:
a.      Don?t redefine standard headers (avoid duplication)
b.      Use the name of the element as the name of the Infoset property 
(don?t reinvent names)
c.      All Infoset properties should be defined and have descriptions
d.      The mapping from Infoset to XML representation should also contain 
appropriate description and make it as clear as possible what is 
happening.
e.      Make sure to use valid types (like wsa:EndpointReferenceType) in 
all definitions Infoset and XML.
 
Are there more principles that we have missed?
 
--Geoff
 
 
From: Chou, Wu (Wu) [mailto:wuchou@avaya.com] 
Sent: Tuesday, February 17, 2009 8:18 AM
To: Geoff Bullen; Doug Davis
Cc: public-ws-resource-access@w3.org; 
public-ws-resource-access-request@w3.org
Subject: RE: WS-Eventing issue 6424 proposal
 
Hi Geoff,
 
We add our answers/comments in line and thanks for your questions.
 
- Wu Chou
 

From: Geoff Bullen [mailto:Geoff.Bullen@microsoft.com] 
Sent: Monday, February 16, 2009 5:49 PM
To: Chou, Wu (Wu); Doug Davis
Cc: public-ws-resource-access@w3.org; 
public-ws-resource-access-request@w3.org
Subject: RE: WS-Eventing issue 6424 proposal
Hi Wu,
There are a number of questions raised from your proposal.
1.      Is it possible to check that the Infoset description will actually 
produce the XML enclosed in the spec (and the examples in the spec)?  How 
can the editors and the WG in general be sure the two descriptions remain 
compatible? 
Wu: There is no requirement to mechanically produce xml from Infoset. The 
mapping from Infoset to xml (WSDL) is normatively specified by the 
standard. The Infoset and xml are from the same set of xml elements 
specified by the standard.
 
2.      If there are inconsistencies between Infoset and XML, who wins? 
Wu: This is a big "if" an it should not happen as explained in 1. But even 
with this big "if", it follows the XML (WSDL), since the Infoset to XML is 
normatively specified. 
 
 3.      In all the examples in Addressing Core [1], they explain the 
mapping between Infoset and XML. For example, below Example 3.2 in 
Addressing Core it says:
This message would have the following property values:
·        [destination]: "http://example.com/business/client1"
·        [action]: "http://example.com/fabrikam/mail/DeleteAck"
·        [message id]: "http://example.com/someotheruniquestring"
·        [relationship]: ("http://www.w3.org/2005/08/addressing/reply", "
http://example.com/someuniquestring")
It would seem like we should also do this too, to be consistent?  Or does 
this make the spec harder to read? 
Wu: To minimize changes, we defined the mapping in the xml section, 
instead of the Infoset section. This helps the readability and keeps the 
structure of original standard. We are reluctant to split WS-Eventing into 
three specs of core, soap/wsdl, and meta information as in WS-Addressing.
 
4.      Are there any files, other that the spec itself, that need to be 
created or updated, associated with doing this work?  For example, is 
there a normative file that contains just the Infoset definitions, similar 
to a schema file, that would be used by various tools? 
Wu: No 
 
5.      If Infoset is seen as the normative description, what should we 
interop on?  Do we all agree to still interop on the XML format?  Do we 
need to interop on more than one format in order to prove the Infoset 
description is valid?  
Wu: We interoperate on xml which is defined by the wsdl. Because the 
Infoset and xml are equivalent, interoperating on xml is equivalent to 
interoperating on Infoset. 
 
6.      If WG decides to do this, it needs to be done for all 5 specs.  Is 
the WG up for that work?  
Wu: Adopting Infoset has many advantages. It is up to the WG to decide, 
but there is a way to incorporate Infoset without changing the original 
structure of the specs.
 
Cheers,
--Geoff
 
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Chou, Wu 
(Wu)
Sent: Friday, February 06, 2009 8:41 AM
To: Doug Davis
Cc: public-ws-resource-access@w3.org; 
public-ws-resource-access-request@w3.org
Subject: RE: WS-Eventing issue 6424 proposal
 
Doug,
 
Your observation is roughly right, since we try to use the original text 
as much as possible and minimize the changes for a first draft. Here is 
the color marked copy with all changes in red color for comparison.
 
Thanks,
 
- Wu Chou.
 
Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA | 233 
Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax: 
908-696-5198 / 908-696-5401 | wuchou@avaya.com

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Wednesday, February 04, 2009 7:49 PM
To: Chou, Wu (Wu)
Cc: public-ws-resource-access@w3.org; 
public-ws-resource-access-request@w3.org
Subject: Re: WS-Eventing issue 6424 proposal

Wu, 
 its hard to tell what's changed w/o redlines.  It appears like the 
section that lists the abstract properties (3.1) is the only new stuff - 
is that correct? 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com 

"Chou, Wu (Wu)" <wuchou@avaya.com> 
Sent by: public-ws-resource-access-request@w3.org 
02/03/2009 03:28 PM 


To
<public-ws-resource-access@w3.org> 
cc

Subject
WS-Eventing issue 6424 proposal
 








 
  
Wu Chou, IEEE Fellow, Ph.D. | Director |Avaya Labs Research | AVAYA | 233 
Mt. Airy Road| Rm. 2D48 | Basking Ridge, NJ 07920 | Voice/Fax: 
908-696-5198 / 908-696-5401 | wuchou@avaya.com 
 [attachment "wse_6424_2.pdf" deleted by Doug Davis/Raleigh/IBM]