wsrp-interop message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp-interop] Quick note on Event payload and Property value elementnames
- From: Richard Jacob <richard.jacob@de.ibm.com>
- To: "Nader Oteifa" <nader2@netunitysoftware.com>
- Date: Fri, 30 Oct 2009 09:55:01 +0100
Well, both statements are not conformance
statements.
From a practival point of view it doesn't
to much sense but can be helpful as we discussed in the other threads.
In regards of changing/clarifying it:
that's why we discuss it here.
Mit freundlichen Grüßen / Kind
regards
|
|
|
|
|
|
|
|
|
Richard Jacob
|
|
|
|
|
|
|
|
|
Team Lead Portal
Standards & WCM development
WSRP Standardization Lead
|
|
|
IBM Software Group,
WPLC
|
|
|
WSS Websphere Portal
Foundation Development 1
|
|
|
|
|
|
Phone:
| +49-7031-16-3469
| IBM Deutschland Research
& Development
|
|
|
|
E-Mail:
| richard.jacob@de.ibm.com
| Schoenaicher Str. 220
|
|
|
|
| 71032 Boeblingen
|
|
|
|
| Germany
|
|
|
|
|
|
IBM Deutschland Research
& Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Erich Baier
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294
|
| |
From:
| "Nader Oteifa" <nader2@netunitysoftware.com>
|
To:
| <wsrp-interop@lists.oasis-open.org>
|
Date:
| 10/29/2009 10:14 PM
|
Subject:
| [wsrp-interop] Quick note on Event payload
and Property value element names |
Per the specification on properties:
“If this property's value is not carried
within the stringValue alternative of the Property structure, this name
also becomes the name of the XML element carrying the property's value
with the type field defining the type of this element.”
Per specification on events:
“If this event's payload is not carried
within the NamedStringArray alternative of the EventPayload structure,
this name also becomes the XML element name carrying the payload with the
type field defining the type of the element.”
You cannot interpret these statements to
mean anything other than what they state: “…this name ALSO BECOMES
the name of the XML element carrying…”. If the name of the element
could be anything, it would not make sense for this part of the statement
to be present. It’s not optional; the names have to match per the
specification.
The way I see it, there is consistency across
the whole specification with respect to the arbitrary root element names
matching the names of a properties, events or extension parts. Whether
this consistency is warranted or causes restriction in implementations
can be further debated; it is what is. If we want to change it, then
we need to formally change it via some errata or some other formal OASIS
procedure.
To me, it’s just an extra restriction during
implementation and does not reflect on the consistency or semantics of
the specification.
Nader
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]