[ann] oXygen XML editor version 11.2 and some more news
Hi, I am pleased to announce that a new version of oXygen is available from our website http://www.oxygenxml.com For the complete list of new features and details please see http://www.oxygenxml.com/index.html#new-version We have an @oxygenxml user on Twitter so you may want to follow that for oXygen related updates http://twitter.com/oxygenxml We plan to have that more active in the future. I also just set up a few hours ago a Facebook page for oXygen: http://www.facebook.com/pages/oXygen-XML-Editor/107247659293674 Until now 17 people registered as oXygen fans, including me :) oXygen was one of the sponsors at XML Prague last week. I had there a presentation on schema-aware editing, and participated in a panel on XML editing tools. If you did not attend the conference you should be able to watch the recordings of the sessions soon, when they will be posted on the conference website http://www.xmlprague.cz/2010/index.html We plan to be a sponsor also at Balisage this year and to exhibit at the DITA Europe conference. We plan also to have a number of online meetings to present some of the oXygen features. It will be great if you can send us feeback on what topics you would find useful to be included in these presentations. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
Years ago, I set up a collection of schemas that use abstract elements and substitution groups to allow different models for certain elements. I just noticed that instance documents that use these schemas have always validated with the default processor (Xerces), and they appear to validate with MSXML 4.0, they don't validate with Saxon-EE or MSXML.NET. XML is a small part of what I do, so I'm not confident that my interpretation of the spec is correct. I've attached a test case that replicates the behavior I'm seeing in a minimal package. I'd appreciate it if someone could look it over and tell me who's right. I think the documents explain themselves, but I'm happy to provide more information about anything that's not clear.
Hi Jesse, It seems to be a limitation in Saxon-EE, it does not read xsi:schemaLocation information from the inner element. The XML Schema specification says that the xsi:schemaLocation can appear anywhere in the document, see point 4 from http://www.w3.org/TR/xmlschema-1/#schema-loc *** 4. xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes] can occur on any element. However, it is an error if such an attribute occurs after the first appearance of an element or attribute information item within an element information item initially ·validated· whose [namespace name] it addresses. According to the rules of Layer 1: Summary of the Schema-validity Assessment Core (§4.1), the corresponding schema may be lazily assembled, but is otherwise stable throughout ·assessment·. Although schema location attributes can occur on any element, and can be processed incrementally as discovered, their effect is essentially global to the ·assessment·. Definitions and declarations remain in effect beyond the scope of the element on which the binding is declared. *** A solution is to move the schema location information to the root element, like: <?xml version="1.0" encoding="UTF-8"?> <testRoot xmlns ="testRoot" xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="testRoot testRoot.xsd testConcrete testConcrete.xsd"> <testChild xmlns="testConcrete"> <data>some stuff</data> </testChild> </testRoot> Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 1/18/11 8:55 PM, Jesse Pelton wrote:
Years ago, I set up a collection of schemas that use abstract elements and substitution groups to allow different models for certain elements. I just noticed that instance documents that use these schemas have always validated with the default processor (Xerces), and they appear to validate with MSXML 4.0, they don't validate with Saxon-EE or MSXML.NET. XML is a small part of what I do, so I'm not confident that my interpretation of the spec is correct. I've attached a test case that replicates the behavior I'm seeing in a minimal package. I'd appreciate it if someone could look it over and tell me who's right.
I think the documents explain themselves, but I'm happy to provide more information about anything that's not clear.
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
Thanks. That makes Saxon-EE work, but MSXML.NET still fails: "The element 'testRoot' in namespace 'testRoot' has invalid child element 'testChild' in namespace 'testConcrete'. List of possible elements expected: 'testAbstract:testChild'." This leads me to wonder if there's something wrong with how I have the substitution group set up. Note that my goal is to be confident that the schemas are correct, not necessarily to make instance documents validate with particular processors. So, if my schemas are correct and MSXML.NET can't validate my documents, I just won't use MSXML.NET. Since Xerces and Saxon-EE now validate the test case, I'm inclined to think I'm right and Microsoft has it wrong. -----Original Message----- From: George Cristian Bina [mailto:george@oxygenxml.com] Sent: Wednesday, January 19, 2011 4:04 AM To: Jesse Pelton Cc: oXygen-user@oxygenxml.com Subject: Re: [oXygen-user] Abstract elements and substitution groups Hi Jesse, It seems to be a limitation in Saxon-EE, it does not read xsi:schemaLocation information from the inner element. The XML Schema specification says that the xsi:schemaLocation can appear anywhere in the document, see point 4 from http://www.w3.org/TR/xmlschema-1/#schema-loc *** 4. xsi:schemaLocation and xsi:noNamespaceSchemaLocation [attributes] can occur on any element. However, it is an error if such an attribute occurs after the first appearance of an element or attribute information item within an element information item initially ·validated· whose [namespace name] it addresses. According to the rules of Layer 1: Summary of the Schema-validity Assessment Core (§4.1), the corresponding schema may be lazily assembled, but is otherwise stable throughout ·assessment·. Although schema location attributes can occur on any element, and can be processed incrementally as discovered, their effect is essentially global to the ·assessment·. Definitions and declarations remain in effect beyond the scope of the element on which the binding is declared. *** A solution is to move the schema location information to the root element, like: <?xml version="1.0" encoding="UTF-8"?> <testRoot xmlns ="testRoot" xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="testRoot testRoot.xsd testConcrete testConcrete.xsd"> <testChild xmlns="testConcrete"> <data>some stuff</data> </testChild> </testRoot> Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 1/18/11 8:55 PM, Jesse Pelton wrote:
Years ago, I set up a collection of schemas that use abstract elements and substitution groups to allow different models for certain elements. I just noticed that instance documents that use these schemas have always validated with the default processor (Xerces), and they appear to validate with MSXML 4.0, they don't validate with Saxon-EE or MSXML.NET. XML is a small part of what I do, so I'm not confident that my interpretation of the spec is correct. I've attached a test case that replicates the behavior I'm seeing in a minimal package. I'd appreciate it if someone could look it over and tell me who's right.
I think the documents explain themselves, but I'm happy to provide more information about anything that's not clear.
_______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com http://www.oxygenxml.com/mailman/listinfo/oxygen-user
participants (2)
-
George Cristian Bina -
Jesse Pelton