- From: Chou, Wu (Wu) <wuchou@avaya.com>
- Date: Tue, 24 Feb 2009 13:27:04 -0500
- To: "Geoff Bullen" <Geoff.Bullen@microsoft.com>, "Doug Davis" <dug@us.ibm.com>
- Cc: <public-ws-resource-access@w3.org>, <public-ws-resource-access-request@w3.org>
- Message-ID: <F81BDFA28AE48D4793E253362D1F7A747A0767@300813ANEX2.global.avaya.com>
Geoff,
The key point to make here is regarding your comment #2, i.e. [event
source] is a critical Infoset element for Eventing spec. The "wsa:To"
specifies the content of the [event source] Infoset element for
Eventing, and it is not to define addressing header.
We add some brief comments for the rest of your comments inline.
Many thanks,
- Wu Chou.
________________________________
From: Geoff Bullen [mailto:Geoff.Bullen@microsoft.com]
Sent: Tuesday, February 24, 2009 10:40 AM
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
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.
Wu: This looks good.
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.
Wu: [event source] and "wsa:To" are critically required (see comment
above).
3)
Infoset property names should be the same as the associated XML element
names. Thus it should be: [endto] not [endto endpoint].
Wu: We agree with this principle.
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)
Wu: Same comment as item 2.
b. Use the name of the element as the name of the Infoset property
(don't reinvent names)
Wu: Same as item 3.
c. All Infoset properties should be defined and have descriptions
Wu: It has already been provided in the subscription template.
d. The mapping from Infoset to XML representation should also
contain appropriate description and make it as clear as possible what is
happening.
Wu: We follow the convention of Infers and XML definition by providing
Infoset and the concrete XML mapping template. We should avoid adding
words, since it is verbose and not precise.
e. Make sure to use valid types (like wsa:EndpointReferenceType) in
all definitions Infoset and XML.
Wu: Agree and will do a check.
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
<blocked::mailto:wuchou@avaya.com>
[attachment "wse_6424_2.pdf" deleted by Doug Davis/Raleigh/IBM]
Received on Tuesday, 24 February 2009 18:27:55 UTC