| |
Comment: |
Email of 4th Sept '08 (15:56)
> Hi Michel,
>
> The only queries I have are:
>
> 1) In the situation where someone defines the jsdl namespace to be the default namespace and tries to reference a jsdl element in the XPath
expression e.g.:
>
> <TotalCPUCount>4</TotalCPUCount>
>
> <sweep:Match>//TotalCPUCount</sweep:Match>
>
> we're currently saying a NamespaceBinding must be declared yet I presume that it would be not be required - as such should the NamespaceBinding
element have a minOccurs of 0?
In XML Documents, as you say, a default namespace may be declared. As a consequence, the namespace prefix is not used for those elements that shall
be taken from the default namespace, yet there is still a namespace present and always defined for that element in question. In short, in XML
Documents that are validated against a XML Schema that declares "elementDefault=qualified" any XML element and attribute is associated with a
namespace, at the very least a *default* namespace. JSDL and JSDL Parameter Sweeps both declare that elements (do we do that for attributes, too?)
must be qualified at all times.
Different for XPath expressions. In XPath one can use elements and attributes that do have namespaces and elements and attributes that have *no*
namespace(!). XPath does not have a notion (AFAIK) of a default namespace, i.e. either elements and attributes have no namespace (like your
TotalCPUCount example) or the do have a namespace, which MUST be used using a bound prefix.
So your example expression must be changed to the following:
<sweep:Match>//jsdl:TotalCPUCount</sweep:Match>
given that the "jsdl" prefix is bound to the JSDL 1.0 namespace.
> 2) In Donal's original response he notes the uniqueness of the prefix values. If required I think that this could be achieved through use of :
>
>> <xsd:element name="DocumentNode"
>> substitutionGroup="sweep:Parameter">
>> <xsd:complexType>
>> <xsd:sequence>
>> <xsd:element ref="sweep:NamespaceBinding"
>> minOccurs="1" maxOccurs="unbounded" />
>> <xsd:element name="Match" type="xsd:string" />
>> </xsd:sequence>
>> </xsd:complexType>
>> <xsd:unique name="uniqueNsBindingPrefix">
>> <xsd:selector xpath="sweep:NamespaceBinding" />
>> <xsd:field xpath="@prefix" />
>> </xsd:unique>
>> </xsd:element>
By way of XML Schema elements you are right. By way of experience and tooling support I strongly advice against using xsd:unique to enforce
uniqueness on the prefixes. My experience shows me that a textual constraint using MUST and MUST NOT etc works far better and is less of confusion
in interop sessions.
So I would prefer keeping the text as it is right now.
> 3) We may also need to make a minor change to section 3.1, paragraph 2, of the spec. e.g.
>
> Current: "The type of the DocumentNode element is an XPath 2.0 expression [XPATH].."
> ChangeTo: "The type of the DocumentNode's Match element is an XPath 2.0 expression [XPATH].."
|
