True. But not sure we care.
On Mon 25 Mar 2013 02:59:13 PM CDT, Gunnar Morling wrote: > |>|2) I am not sure what exact scenario you are are thinking about, but I do > not see any problem with validating a 1.0 or 2.0 compliant doc with the 2.1 > xsd. > I meant cases like this: > > <entity-mappings version="1.0"> > ... > <persistence-unit-defaults> > <delimited-identifiers/> > </persistence-unit-defaults> > ... > </entity-mappings> > > This would not be legal as per the 1.0 schema, since > "delimited-identifiers" was only added in 2.0. > > Validating with the latest schema wouldn't detect this kind of error, > but as said, it might well be that this can be neglected. If not, a > separate validation using the original schema version would detect the > error. > > > 2013/3/25 Steve Ebersole <st...@hibernate.org > <mailto:st...@hibernate.org>> > > Well I just noticed that the class is at least attempting to also > alter the version in the StAX events. We'll just have to wait to > hear from Strong whether this setup currently out on github works > or not. It is essentially the approach discussed on IRC. > > As for performing the validation up front: > 1) I have had no success getting this to work on master, where I > am trying to do something similar (version specific validation). > The validation always passes > 2) I am not sure what exact scenario you are are thinking about, > but I do not see any problem with validating a 1.0 or 2.0 > compliant doc with the 2.1 xsd. > > > > On Mon 25 Mar 2013 02:34:11 PM CDT, Gunnar Morling wrote: > > Yes, version attribute and namespace would have to be updated > to the > 2.1 values. > > IMO it would still make sense to have a validation step using the > original schema (e.g. the 1.0 one) before, since validation > with the > 2.1 schema wouldn't reject any (wrong) elements in e.g. a 1.0 > document > which where actually added in a later schema version. Or would you > tolerate this kind of error? > > > 2013/3/25 Steve Ebersole <st...@hibernate.org > <mailto:st...@hibernate.org> > <mailto:st...@hibernate.org <mailto:st...@hibernate.org>>> > > > I assume LegacyJPAEventReader is the attempt to work > around that > in the general approach discussed? > > I wonder if that is working though, as for sure another > thing we > need to do there is to alter the version attribute > returned on the > root. If the incoming orm.xml, for example, says 1.0 as the > version and we only update the namespace and attempt to > validate > with the 2.1 xsd, the validation will still fail. The > reason is > that the XSDs define the version value statically. > > > > On Mon 25 Mar 2013 11:18:53 AM CDT, Steve Ebersole wrote: > > We just had a great discussion with Eric on IRC. > > Essentially his suggestion (along the same lines the > Gunnar > suggested) > was to use xslt to adjust the incoming documents to one > version (the > latest) of the xsd and use that for jaxb. > > An xslt for such a transformation can be seen here: > > http://stackoverflow.com/____questions/3463943/changing-____namespace-for-xml-file-in-xsl-____translation > > <http://stackoverflow.com/__questions/3463943/changing-__namespace-for-xml-file-in-xsl-__translation> > > > > <http://stackoverflow.com/__questions/3463943/changing-__namespace-for-xml-file-in-xsl-__translation > > <http://stackoverflow.com/questions/3463943/changing-namespace-for-xml-file-in-xsl-translation>> > > > > On Mon 25 Mar 2013 10:38:51 AM CDT, Gunnar Morling wrote: > > > Hi Strong, > > As per my understanding of JAXB, you can't use one > set of > JAXB binding > classes for unmarshalling XML files which use > different > schemas (or > different namespaces). > > I can see the following options: > > 1) Generate different sets of binding classes for the > different XSD > versions (namespaces) and use the right set of > classes for > unmarshalling a > given document based on the schema version it uses. > > That's simple to follow but comes at the price of high > redundancy > between > the sets of binding classes and likely requires > tedious > copying logic to > e.g. populate the new binding classes based on the > old ones. > > 2) Separate validation and unmarshalling into separate > steps. First > perform > validation of the given instance document against the > schema version it > uses (which could be discovered by e.g. examining the > "version" or the > "xmlns" attribute of the root element). > > If validation succeeds, perform a separate > unmarshalling > step, where the > binding classes would only exist for the newest schema > version. When > unmarshalling a "new" instance document, nothing > further > is required, > when > unmarshalling an "old" document, a transformation > of that > document > would be > required, to make it adhere to the current schema > and expected > namespace of > the binding classes. Assuming that the schema was > evolved in a > compatible > manner (meaning old documents also adhere to the new > schema except the > value of the "version" attribute and the > namespace), this > transformation > should be a simple transformation with XSLT, using the > "self-transformation" pattern. > > The second approach is a bit more complex (and > might be a > bit more > costly > due to the transformation), but it requires only > one set > of binding > classes > and frees the application code from dealing with > different > schema > versions. > > I found > http://www.funkypeople.biz/____knowledge/JavaXml-v2.pdf > <http://www.funkypeople.biz/__knowledge/JavaXml-v2.pdf> > > > <http://www.funkypeople.biz/__knowledge/JavaXml-v2.pdf > <http://www.funkypeople.biz/knowledge/JavaXml-v2.pdf>> to be an > interesting read on that matter. > > Hth, > > --Gunnar > > > > 2013/3/25 Strong Liu <st...@hibernate.org > <mailto:st...@hibernate.org> > <mailto:st...@hibernate.org > <mailto:st...@hibernate.org>>> > > > > Hi JAXB expert > > I'm trying to do the merge master onto metamodel > again, but run into > some > JAXB problems and I'd like to ask for suggestions. > > as you know, we compile the orm.xsd to jaxb > generated > class, and > there is > a package-info.java generated for schema > validation, > this class > looks like > > {code} > > @javax.xml.bind.annotation.____XmlSchema(namespace = " > http://java.sun.com/xml/ns/____persistence/orm > <http://java.sun.com/xml/ns/__persistence/orm> > > <http://java.sun.com/xml/ns/__persistence/orm > <http://java.sun.com/xml/ns/persistence/orm>>", > elementFormDefault = > javax.xml.bind.annotation.____XmlNsForm.QUALIFIED) > > package org.hibernate.jaxb.spi.orm; > {code} > > > but due to the namespace of orm.xsd changed > since JPA > 2.1 ( from " > http://java.sun.com/xml/ns/____persistence/orm > <http://java.sun.com/xml/ns/__persistence/orm> > <http://java.sun.com/xml/ns/__persistence/orm > <http://java.sun.com/xml/ns/persistence/orm>>" to " > http://xmlns.jcp.org/xml/ns/____persistence/orm > <http://xmlns.jcp.org/xml/ns/__persistence/orm> > > <http://xmlns.jcp.org/xml/ns/__persistence/orm > <http://xmlns.jcp.org/xml/ns/persistence/orm>>", btw, > any idea why? ) > > for now, I created a > > org.hibernate.jaxb.internal.____LegacyJPAEventReader, > > which will modify the legacy namespace to the > new one > ( also > changing the > version to 2.1 ) > but with this applied, the jaxb schema > validation is > always fail no > matter > which schema is used. > > so, I came up with another idea, if the original > orm.xml is 2.1 then go > ahead with jaxb validation, or, we disable > jaxb schema > validation > and apply > stax schema validation before > > org.hibernate.jaxb.internal.____LegacyJPAEventReader > > came into play > > ( see > > org.hibernate.jaxb.internal.____JaxbMappingProcessor#unmarshal > > ) > sadly, > it doesn't work :( validation still fail, can be > reproduced by > > > org.hibernate.metamodel.____internal.source.annotations.____xml.OrmXmlParserTests#____testInvalidOrmXmlThrowsExcepti____on > > > > so, any suggestions? > ------------------------- > Best Regards, > > Strong Liu <stliu at hibernate.org > <http://hibernate.org> <http://hibernate.org>> > http://about.me/stliu/bio > > > > > ___________________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org> > <mailto:hibernate-dev@lists.__jboss.org > <mailto:hibernate-dev@lists.jboss.org>> > https://lists.jboss.org/____mailman/listinfo/hibernate-dev > <https://lists.jboss.org/__mailman/listinfo/hibernate-dev> > > <https://lists.jboss.org/__mailman/listinfo/hibernate-dev > <https://lists.jboss.org/mailman/listinfo/hibernate-dev>__> > > > ___________________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org> > <mailto:hibernate-dev@lists.__jboss.org > <mailto:hibernate-dev@lists.jboss.org>> > https://lists.jboss.org/____mailman/listinfo/hibernate-dev > <https://lists.jboss.org/__mailman/listinfo/hibernate-dev> > > <https://lists.jboss.org/__mailman/listinfo/hibernate-dev > <https://lists.jboss.org/mailman/listinfo/hibernate-dev>__> > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
