- From: Doug Davis <dug@us.ibm.com>
- Date: Fri, 27 Feb 2009 15:41:38 -0500
- To: "Chou, Wu (Wu)" <wuchou@avaya.com>
- Cc: "Geoff Bullen" <Geoff.Bullen@microsoft.com>, public-ws-resource-access@w3.org, public-ws-resource-access-request@w3.org
- Message-ID: <OF67A595ED.DF5091C6-ON8525756A.00710865-8525756A.0071AEB2@us.ibm.com>
This shows a possible inconsistency that I think Geoff was concerned
about. The infoset stuff say:
[event source]: wsa:[endpoint reference] (1..1)
And in the xml section it says:
/s:Envelope/s:Header/wsa:To, /s:Envelope/s:Header/xs:any
These OPTIONAL elements provide the value of the [event source]
Property.
Is [event source] required (per the cardinality shown in the infoset) or
optional (per the xml section) ?
Perhaps you should remove the cardinality text "(1...1)" from the infoset
section?
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/27/2009 03:25 PM
To
"Geoff Bullen" <Geoff.Bullen@microsoft.com>
cc
<public-ws-resource-access@w3.org>,
<public-ws-resource-access-request@w3.org>
Subject
RE: WS-Eventing issue 6424 proposal
Geoff,
Here are clean and change marked copies of the Infoset based Subscribe
Section of Eventing that incorporate your comments.
Some additional info regarding the updates are:
1. Regarding comment 4e & 4a, we updated the last sentence of the first
paragraph in Section 3.1. It is revised to "where wsa:[endpoint reference]
refers to the Information Model for Endpoint Reference defined in Section
2.1 of WS-Addressing 1.0 Core". We used this abstract property , where
its property and its mapping to XML wsa:EndpointReferenceType are defined
in Section 2.1 WS-Addressing 1.0 Core.
2. Regarding comment 3 "[endto] not [endto endpoint]" & 4b, we followed
the convention of WS-Addressing that it has endpoint in the local name of
the abstract property, e.g. WS-Addressing Core 3.1, [source endpoint],
[reply endpoint], ... These are local names of the abstract properties and
they can be more informative (not necessarily to be exactly as the xml
element name e.g. WS-Addressing Core Section 3.1 ) .
Many thanks,
-Wu Chou
From: Chou, Wu (Wu)
Sent: Tuesday, February 24, 2009 1:27 PM
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
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
[attachment "wse_6424_2.pdf" deleted by Doug Davis/Raleigh/IBM]
[attachment "wse_6424_3_clean.pdf" deleted by Doug Davis/Raleigh/IBM]
[attachment "wse_6424_3_marked.doc" deleted by Doug Davis/Raleigh/IBM]
Received on Friday, 27 February 2009 20:42:27 UTC