Hi Jorge, On Thu, Jun 14, 2012 at 5:44 PM, Jorge Williams <jorge.willi...@rackspace.com> wrote:
> I couldn't find anything in the standard that says that implementation must > have typed nodes The XSD 1.1 assertions spec here describes how the XDM data model for assertions need to be constructed, http://www.w3.org/TR/xmlschema11-1/#sec-cvc-assertion The paragraph "Validation Rule: Assertion Satisfied" says, 1 A data model instance (see [XDM]) is constructed in the following way: 1.1 E is validated ... 1.2 A "partial" ·post-schema-validation infoset· describing the results of this partial validation of E is constructed. 1.3 From the "partial" ·post-schema-validation infoset·, a data model instance is constructed as described in [XDM]. I think, this does imply that the assertions XDM tree must have typed nodes. Note that, the root node of the assert XDM tree is 'untyped' before assertions are evaluated (and all other nodes of assert tree are typed, before assertion evaluations). > so I don't think that they are doing anything wrong by requiring the cast. The problem that I face is that I don't know what XSD > implementation my end users will be using, so I have to make sure that my > XSDs work correctly no matter what. If your > implementation can't handle the cast correctly, I'd be forced to write two > versions of an XSD, one for Xerces (without casts) and one > for Saxon (with > casts) -- I find myself in this situation today and I don't think it's > acceptable. As Michael noted in his previous email > it's a total pain -- > having to write implementation specific versions of an XSD defeats the > purpose of having a standard in the first > place. If making explicit casts in this case, helps users we would certainly try to implement it :) > Please fix this bug :-) Definitely. But I can't promise, how soon this can be implemented since changing PsychoPath XPath engine internals for this need may not be quite trivial. -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
