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