Logged as http://www.osoa.org/jira/browse/BINDINGS-140
-Eric.
On 10/19/10 2:19 AM, Simon Holdsworth wrote:
OFA71FEF68.84415412-ON802577C1.002F4D65-802577C1.003309C9@uk.ibm.com"
type="cite">TARGET: SCA JMS
Binding Specification cd04-rev1
DESCRIPTION:
(I have a sense of deja vu
writing this,
I'm sure we discussed this at some point but I cannot find an
open issue
related directly to this)
The JMS binding defines several
places
where user properties can be specified, either to be used within
a message,
or to be used when created resources.
These properties make use of the
BindingProperty
type:
<complexType
name="BindingProperty">
<simpleContent>
<extension
base="string">
<attribute name="name" type="NMTOKEN" use="required"/>
<attribute name="type" type="string" use="optional"
default="xs:string"/>
</extension>
</simpleContent>
</complexType>
Given the default value specified
for
the "type" attribute it appears that the value space of the type
attribute is some set of XML schema types. However nowhere in
the
JMS spec is the set of values of the "type" attribute defined.
I hit this issue when looking at
testcases
BJM_30025_1 and BJM_30025_2, where we currently only test the
setting of
a string-type JMS user property, and my desire was to test
setting one
of each possible type, but "possible type" is not defined in
the JMS binding specification.
Where the BindingProperty type is
used
for defining resources (destinations, connection factories,
etc.), then
I am OK with the value space being open-ended, as this is
supposed to be
a mechanism for extensibility.
However, where BindingProperty
type
is used for specifying JMS user properties in messages that are
sent, there
is a specific limited set of types that can be used.
Related to this, the
pseudo-schema shows
all property elements as having a type attribute of type
"NMTOKEN"
but in the schema the type is "string".
PROPOSAL:
We should specify the set of
values
of the "type" attribute of the BindingProperty when used to
specify
a JMS user property. The JMS spec defines the following types
for
user properties: boolean,
byte, short, int, long, float,
double,
and String. There
is a direct
mapping of these to XML schema type names: xs:boolean, xs:byte,
xs:short,
xs:int, xs:long, xs:float, xs:double and xs:string. Although
this
seems fairly obvious it is not spelled out in the spec.
Section
3.2 contains the normative statements that define the behaviour
of JMS
user properties, so I think that is the best place for this.
Given
that we already have a normative statement which says that the
properties
must be set with the name and type specified, I think it is OK
to add a
non-normative statement which defines the mapping.
In terms of specifying the valid
values,
I'm unsure of whether those values would include the "xs:"
prefix.
Note that the default value for the type attribute is defined
in
the schema as "xs:string" so it would be consistent that the
set of values also starts with "xs:".
Specific changes:
Update the pseudo-schema to
replace
all instances of: <property name=”NMTOKEN”
type=”NMTOKEN”?>*
with: <property
name=”NMTOKEN”
type=”string”?>*
Update section 3.2 to add a
paragraph
after the initial paragraph (at line 320):
The JMS specification supports
the following
user property types: boolean, byte, short, int, long, float,
double, and
String. These are identified via the property/@type attribute
using
the following values: "xs:boolean", "xs:byte", "xs:short",
"xs:int", "xs:long", "xs:float", "xs:double"
and "xs:string" respectively.
Possible alternative:
An alternative solution would be
to
define a separate type for specifying UserProperties and define
the type
attribute as an enumeration allowing schema validation of these
values,
but at this point that is a much more significant impact.
Regards, Simon
Simon Holdsworth
Unless stated otherwise
above:
IBM United Kingdom Limited - Registered in England and Wales
with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth,
Hampshire PO6
3AU
|