|
| Re: Request for Comment: Defect #122770. [message #49399 is a reply to message #49334] |
Fri, 06 January 2006 12:29   |
 Brent A. Miller
Messages: 1
Registered: July 2009 |
Junior Member |
|
|
From an architecture perspective, I am in general agreement with the
direction of this proposal. Common Base Event implementations should
ultimately follow the XML schema rules rather than the specific (e.g.,
Java) implementation rendering rules.
One additional consideration: the Common Base Event specification notes
certain properties that should be treated as having "default" values when
they are null (unspecified) (for example, for the version property, the
specification states, "This field is OPTIONAL in that if it isnt
specified, the version of the CBE is said to be 1.0."; for the
extensionName property, the specification states, "If the value specified
is null, then the value is assumed to be CommonBaseEvent.").
Implementations should, in addition to the treatment of null/unspecified
values noted in this defect, also respect these cases where the
specification notes special treatment for null/unspecified values.
|
|
|
| Re: Request for Comment: Defect #122770. [message #49458 is a reply to message #49399] |
Fri, 06 January 2006 14:54 |
Paul Slauenwhite
Messages: 975
Registered: July 2009 |
Senior Member |
|
|
Hi Brent,
Thank you for your reply and comments.
Regarding your point on default values for null or unspecified
properties, I would argue that since the Common Base Event V1.0.1
specification assume the XML convention, null or unspecified properties are
one in the same. As such, it is up to the consume of a Common Base Event
XML fragment to interpret a missing or empty version attribute as one in the
same, for example. Currently, Common Base Event properties, such as
version, are not serialized to XML if they have not been set (e.g. null in
the case of strings and complex objects or denoted by the unset flag in the
case of primitives) to control the size of Common Base Event XML fragments.
We are proposing converting null values explicitly set on a Common Base
Event property to an empty string, thereby serializing the property to an
empty XML attribute (or element in the case of a complex object other than a
string). The consumer of such an empty attribute would interpret it the
same as if the attribute were missing. Otherwise, to maintain consistency,
all null and unset properties would need to be serialized to XML as empty
attributes or elements resulting is artificially bloated Common Base Event
XML fragments.
Paul
"Brent A. Miller" <bamiller@us.ibm.com> wrote in message
news:6f518f1afc8703a096ef7414bf038c38$1@www.eclipse.org...
> From an architecture perspective, I am in general agreement with the
> direction of this proposal. Common Base Event implementations should
> ultimately follow the XML schema rules rather than the specific (e.g.,
> Java) implementation rendering rules.
>
> One additional consideration: the Common Base Event specification notes
> certain properties that should be treated as having "default" values when
> they are null (unspecified) (for example, for the version property, the
> specification states, "This field is OPTIONAL in that if it isn
|
|
|
| Re: Request for Comment: Defect #122770. [message #49672 is a reply to message #49458] |
Mon, 09 January 2006 22:36 |
Eclipse User |
|
|
|
Originally posted by: tawinson.au1.ibm.com
Just to let everyone else know, the new SecurityEventFactory code has run
into problems with this bug. Put succintly, given perfectly valid
parameters, the cbe code is capable of creating an event that will then
fail its own validation. The problem arises in the ExtendedDataElement
code when addChild(name, type, value) is called and value==null. There is
no check for a null value, and the method calls
ede.getValues().add(value). This sets the "value" to an array of null
values, and a size of 1. Validate() later throws an exception when
"value" is not equal to null and has a size>0. I would suggest that
changing this particular occurence of how null values are handled would
not cause negative impact to existing consumers, as I doubt any existing
consumers are using this method this way, otherwise they would have
Exceptions thrown too.
|
|
|
Powered by
FUDForum. Page generated in 0.05677 seconds
] 
Search
Help
Register
Login
Home
