OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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]