Comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Tuesday, August 18, 2009 3:02 AM
To: <[email protected]>
Subject: Re: [2.x] property parsing question
Hi Raymond
Thanks for the info. More questions in line...
It's valid to define a property value as follows if the property type is
a
simple type such as xsd:string.
<property name="prop1">ABC</property>
The isTextForProperty flag stays true if no elements are encountered
under
<property>.
So what is this bit of code doing?
if (PROPERTY_QNAME.equals(name)) {
isTextForProperty = true;
break;
}
At first sight it seems to be checking for
<property>
<property>
</property>
</property>
No, it sets the flag at <property> level. If there is any child element
under <property>, the flag is set to false. We don't check the case where
another <property> element is used under the <property> though.
When we read the property value into a DOM document, the value cannot be
validated as the type might be unknown at this point.
In what circumstances is the type not known?
For example, the component property type is inherited from the
componentType.property.
This leads to corner
cases such as:
1) <property name="prop1"></property>
2) <property name="prop1"/>
The XML spec [1] has two statements about content of an element:
a) "The text between the start-tag and end-tag is called the element's
content."
b) "An element with no content is said to be empty.] The representation
of
an empty element is either a start-tag immediately followed by an
end-tag,
or an empty-element tag."
According to b), 1 and 2 are equivalent and we should report the
violation
if "mustSupply" is true.
There was a more basic problem in the code.
1/ it was adding a text value element to the DOM regardless of whether
one is required of not
2/ the test for a null value was coded as property.getValue() == null
which will never be true as the value is always a DOM documents. The
question becomes whether the DOM root has any child elements. Also
problem 1/ meant that it always had child elements.
We didn't follow a & b. If my understanding of the XML spec is correct, then
we should treat empty element as no content.
In such case, we should not create a DOM.
It seems that a DOM document is always created and if the property has
value(s) they are added as child <value> elements of the DOM's root
element. Is this structure important later on when it comes time to
transform the values into injected properties?
Yes,. we try to normalize the property value to under the <value> element to
facilitate the data transformation.
But now what's the value to set prop1 to "" if its type is xsd:string?
3) <property name="prop1" value=""></property>
4) <property name="prop1"><value></value></property>
I'm sure 3 is valid. 4 seems to have a value without content. Is it the
same
as 1 & 2?
Good question to which I don't have a good answer. Maybe we only allow
an empty string to be represented using 3).
if there are some characters in the content for the property or value
element, then I assume the "mustSupply" is satisfied and it becomes a
matter
of value validity. For example, if the type cannot accept the text as the
literal value, for example "xsd:int" cannot take "A" or complex types
(mixed="false") cannot take simple text.
Another interesting point is that if we want to set the property value to
be
null, I think we should probably use xsi:nil="true" using the following
styles:
5) <property name="prop1"><value xsi:nil="true"/></property> <!-- it
requires the sca:value element to be nillable -->
6) <property name="prop1"><prop1 xsi:nil="true"
xmlns":xsi="..."/></property> <!-- the propery is defined as a global
element with nillable="true" -->
Ideally, the SCA spec should cover about all these situations to leave no
space for ambiguity.
Right.
