Yea, I think the data model thing is definitely the biggest issue. Part of the goal of XmlSchema was to have a representation that could be used by a "GUI" or something to help create/edit schemas. Also, the obvious "java first" cases where we need to convert Java objects to schema requires building up a Schema object model that can then write out the schema. It's definitely a different use case than the xerces model. Xerces is targeted at consuming schema (as is xsom I think) whereas XmlSchema has more capabilities for producing Schema.
Dan On Mon April 6 2009 10:30:46 am Benson Margulies wrote: > The data model issue, I think, is the crux here. My belief is that > XmlSchema users need to ingest, modify, and then emit XML documents > containing schema, and I think these documents need to be recognizable to > their original authors when written back out. For example, if a user's > schema uses xs:include or xs:import to pull in a schema from someplace > else, ending up with a schema that just merges the content inline, with no > reference to the original, could be a problem. Things like attribute groups > have a role to play in creating schemas that are readable to humans. > <xs:annotation><xs:documentation>blah</xs:documentation></xs:annotation> is > another thing that would be pretty hard to preserve. > > A programmer working, say, with the CXF Aegis binding, can open a book on > Xml Schema, and find an API that corresponds to the constructs he or she > sees there. In the model you are describing, that person would need to > become familiar with the underlying model. I'm not by any means describing > this as a fatal flaw, just a consideration. > > My decision to allow XmlSchema to depend on 1.5 for my own convenience is > not a big deal. If we were to come up with a plan for a unified approach, I > don't see any problem with retreating in version space. > > I don't, then, see using the Xerces rep as the one-and-only rep as viable, > due to the data model issues. However, it might be that some sharing with > it could make various things more efficient and slimmer. Could one imagine > mapping more directly from the XmlSchema 'surface' objects to a Xerces > model as a more efficient way to obtain a Schema object? > > I probably need to do more reading before commenting further. > > > > On Mon, Apr 6, 2009 at 10:17 AM, Michael Glavassevich > > <[email protected]>wrote: > > Benson Margulies <[email protected]> wrote on 04/06/2009 07:53:53 AM: > > > Folks, > > > > > > I do not know of any way to communicate with the originators of > > > Apache XmlSchema, so I don't think it's productive to explore their > > > motives in retrospect. I'm more interesting in looking forward. > > > > I think it is important to understand what the API is trying to achieve > > and what capability its audience expects to get from it. > > > > Looking at the WS-Commons API I see at least a few things which don't > > naturally fit into Xerces like classes for xs:imports, xs:includes, > > attribute group references, elementFormDefault, etc... These constructs > > aren't part of the data model defined by the schema spec yet I assume > > there was some need to include them in the API and that there are > > possibly users which now depend on them being there. Xerces doesn't hold > > on to any of those things and it would be quite difficult to add them in > > now, both in the implementation and Xerces' API which is stable and needs > > to remain compatible even when we evolve it. Also, I see there's been > > some effort to move towards using Java 5 language features. We only > > recently voted to move to a minimum of JDK 1.3 and given feedback from > > our user community it's still going to be awhile before we would move > > higher than that. > > > > > Apache XmlSchema is \read-write/. One can create an entire schema, > > > from scratch, operating against its abstract data model. If the > > > Xerces model is adaptable in that direction, and the Xerces > > > community is amenable, then it's worth looking into extending the > > > Xerces implementation in this direction. If not, we've discovered, > > > perhaps, why we have two. > > > > > > Your email includes a couple of other implementations of which I am > > > ignorant, so I'm not prepared (yet) to comment on the extent to > > > which users of Apache XmlSchema could do just as well using those. > > > > > > --benson > > > > > > > > > On Sun, Apr 5, 2009 at 11:29 PM, Michael Glavassevich < > > > > [email protected] > > > > > > wrote: > > > > > > 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 -- Daniel Kulp [email protected] http://www.dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
