Xerces has had its own XML Schema API [1][2] for years which has many users. This API is implemented by Xerces-J, C++ and Perl, providing a read-only view of the XML Schema component [3] model which is primarily exposed through PSVI [4]. In Xerces-J the implementation is optimized for schema validation. DOM is an intermediate representation in building it but we throw it out at the end. Keeping it around would bloat memory usage and doesn't fit into the programming model which is schema component centric rather than schema document centric.
I was aware that WS-Commons decided to develop its own API though I must say I never understood why given all the choices which already existed [1][5][6][7]. I just assumed that the community had its reasons, perhaps to support some specific scenarios which don't fit well with the goals of these other APIs. I wouldn't have guessed that it would have been due to ignorance of their existence. Surely someone would have known about at least a few of these before starting this WS-COMMONS project, right? Thanks. [1] http://www.w3.org/Submission/2004/SUBM-xmlschema-api-20040309/ [2] http://xerces.apache.org/xerces2-j/javadocs/xs/index.html [3] http://www.w3.org/TR/xmlschema-1/#concepts-data-model [4] http://xerces.apache.org/xerces2-j/javadocs/xs/org/apache/xerces/xs/ItemPSVI.html [5] http://www.eclipse.org/modeling/mdt/?project=xsd#xsd [6] http://xmlbeans.apache.org/docs/2.4.0/reference/index.html [7] https://xsom.dev.java.net Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected] E-mail: [email protected] Benson Margulies <[email protected]> wrote on 04/05/2009 06:44:24 PM: > Lawrence, > > Historically, that might have been the case or the intention, but > there's nothing 'pull-y' about it today. If you feed it files, it > builds dom and walks dom. If you feed it dom, it just walks dom. > > Now, I'm not an axis2 developer, I'm a cxf developer, but from > inside the code I just can't see how it would be a problem. > > -benson > On Sun, Apr 5, 2009 at 6:22 PM, Lawrence Mandel <[email protected]> wrote: > > Hi Benson, > > I may not be remembering correctly, but I thought that one of the > reasons for developing XmlSchema in WS-COMMONS was to support a pull > based model (Axiom). I completely agree that there should not be > duplication of effort around these models at Apache. (Our collective > time is better served solving other problems.) Do you foresee any > issues (primarily with Axis2) with moving XmlSchema to a strictly > DOM based model? Is this question even relevant? > > Thanks, > > Lawrence > > From: > > Benson Margulies <[email protected]> > > To: > > [email protected] > > Cc: > > Daniel Kulp <[email protected]>, [email protected] > > Date: > > 04/05/2009 05:45 PM > > Subject: > > How many XML Schema libraries at ASF is too many XML Schema Libraries? > > Sent by: > > [email protected] > > > > Dear Xerces-J developers, > > At the moment, I'm the most active maintainer of Apache Xml Schema. > This library, which lives inside the WS-COMMONS project, which lives > inside the Web Services TLP, is a set of Java classes that form a > data model for W3C XML Schema, together with code to walk DOM of > schema documents and build the representation and visa versa. > > XmlSchema has no capability to validate a document against a schema. > Typical applications, such as Apache CXF or Apache Axis, spend a > fair amount of time converting back and forth between XmlSchema > representation and the ordinary DOM for schema documents, if only to > pass them into the SchemaFactory to tee up validation, or into some > other library. > > While I haven't gone spelunking in the code of Xerces yet, the > existence of the validation feature strikes me as strong > circumstantial evidence the existence of some representation of schema. > > It strikes me that two Java class libraries for W3C XML Schema > inside ASF is, prima facia, one too many. So, I'm sending this email > to ask if the Xerces project has interest in working on exposing a > documented API to the XML Schema data model. > > I was am more or less on the verge of putting a significant pulse of > effort into modernization and performance enhancement of XmlSchema, > and if the same effort could yield a more broadly useful result, I'd > like to apply it there. > > I am imagining a scheme where the core representation is dom, using > subclasses of DOM interfaces to supply convenience methods for safe > and comprehensible access to the abstract data model. This could > radically speed up code that needs to handle schema documents as DOM > and also analyze and manipulate the abstract data model of the W3C > Xml Schema. But, imagination aside, I think it would be good to > focus energy on a shared solution. > > > Regards, > Benson Margulies
