(Inline) On Jun 15, 2012, at 1:08 AM, Mukul Gandhi wrote:
> 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). Okay, I'll email the Saxon guys about it. > >> 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 :) It certainly will help me today :-) > >> 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. > > No problem, I understand. I'll start working the issue from the Saxon end. Thank you very much for looking into it, -jOrGe W. --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
