- From: Michael Kay <mike@s...>
- To: Mukul Gandhi <mukulg@s...>
- Date: Tue, 31 May 2022 12:45:14 +0100
| I agree it's not very useful, because it's very unlikely that an assertion on a simple type will reference element names or type names, other than the built-in XSD atomic type names; but it's there for completeness. For example you can write
<xs:assertion xpathDefaultNamespace=" http://www.w3.org/2001/XMLSchema" test="$value castable as dateTime"/>
It's there for orthogonality. If there are lots of use cases for putting the attribute on xs:assert, but only a rather slender use case for putting it on xs:assertion, then it's better to put it on both for the sake of consistency.
Michael Kay Saxonica On 31 May 2022, at 12:08, Mukul Gandhi < mukulg@s...> wrote:
Hi all,
On Tue, May 31, 2022 at 2:09 PM Mukul Gandhi < mukulg@s...> wrote: Is an optional xs:annotation child of xs:assertion, can make use of xpathDefaultNamespace attribute on xs:assertion, or is there any other use case of having xpathDefaultNamespace attribute on xs:assertion?
It seems to me that, xs:annotation child of xs:assertion, cannot make use of xpathDefaultNamespace attribute, since there can never be XPath expressions to be evaluated within xs:annotation.
But my other question still begs for answer. i.e, whether xpathDefaultNamespace attribute has any valid uses with xs:assertion? As far as I know, xs:assertion always has to evaluate XPath expressions involving $value and literals. As per XSD 1.1 spec, $value is "a value consisting of a sequence of zero or more atomic values".
--
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
Cart
