Community
Participate
Working Groups
Where possible the particular calls to the underlying PSVI Implementation of Xerces should be refactored out so that the implementation uses the TypeInfo interface. This provides a more abstract and non-implementation dependent way of determining the relevant information that the processor needs for XML Schema awarness.
Assigning inbox items to triaged since these have all be triaged.
This touches up to bug 296368 (or the other way around). From what I can tell, TypeInfo doesn't give us access to the PSVI infoset and won't provide enough information to determine e.g. fn:nilled. So, while TypeInfo is nice enough for some kinds of queries, it is not a complete solution. And while I agree that "The perfect is the enemy of the good", we should still be looking for the better solution. I've hinted at a possible solution in bug 296368.
(In reply to comment #2) > This touches up to bug 296368 (or the other way around). From what I can tell, > TypeInfo doesn't give us access to the PSVI infoset and won't provide enough > information to determine e.g. fn:nilled. > > So, while TypeInfo is nice enough for some kinds of queries, it is not a > complete solution. And while I agree that "The perfect is the enemy of the > good", we should still be looking for the better solution. I've hinted at a > possible solution in bug 296368. I agree...Ideally the Xerces-J submission to the W3C would have gone some where, but alas it didn't. I'm open to any future design that can do a better job of separation. As it is right now, if it can't find the PSVI interfaces, it basically just doesn't do schema awarness checking beyond the builtin types. There is also the Abstract Schema Object Model, which the current Content Model from WTP is based on a very early draft of this specification. http://www.w3.org/TR/DOM-Level-3-AS/Overview.html
Moving to the XPath component out of XSL.
