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>
>
> 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?
> 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.
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?
>
> 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.
