[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SV: [ubl-dev] Réf. : Re: [ubl-dev] RE: UML meta-modeling of UN/CEFACT Core Components
Duane Nickull wrote: > Not quite sure. > Anyone have opinions about this? > I suppose I didn't really address any of the schema evolution issues from this thread in my previous post. Again, I have to reiterate that I have almost no knowledge of the work happening on UBL, so my comments are coming purely from a generic XML databinding point of view. JAXB 1.0 doesn't address the issue of schema evolution at all - in fact it explicitly states that it is a non-goal. The JAXB 2.0 specification is currently being worked on by the expert group and will address this issue at some level. The ability of JAXB classes generated from the UBL 1.0 schema to handle documents conforming to UBL 1.1 is unknown and likely won't work. It really depends on how the 1.0 schema was written. If there are extension points in the schema, then it might be possible. In general, depending on JAXB classes which, in turn, depend on an evolving UBL schema can be problematic. Our original UBL sample was based on UBL 0p7 and the sheer size and complexity of the schema led us to develop a thin library of facade code on top of it. Our sample app isn't coded to the generated classes directly, but rather to the more manageable facade library. When UBL 1.0 was released, we simply tweaked the implementation of the facade code and left the sample app relatively unchanged. Of course, this strategy doesn't help you write a document processor that is capable of handling documents conforming to different versions of the schema. The proposal of having different namespaces for different versions of the schema helps JAXB. You could generate libraries of Java code for each schema and register them with JAXB. In JAXB, namespaces map directly to Java packages. The JAXB runtime is then capable of determining which packages represent the namespace in question and will instantiate the proper classes. There are many other techniques that can be used to handle this problem as well. We've seen people use XSLT to transform documents from one grammar to another, bind portions of the XML data to DOM trees rather than schema derived classes, etc. Hope that helps... Thanks, --Ryan > Duane > > Anders W. Tell wrote: > >> Duane, >> >> What happens to the impact study if one adds tools such a the free JAXB? >> >> /anders >> >> Duane Nickull wrote: >> >>> Your suggestions, while correct for the UML crowd, will result in a >>> large scale and largely unnecessary amount of coding work to >>> implement the forwards changes. I urge you all not to hardcode class >>> names into elements an class attributes into XML attributes without >>> undertaking an impact study on the poor programmer. >>> >>> I also agree that versioning should be addressed, my arguments are >>> that "thinking" of efficiency when expressing UML models and XML >>> should be undertaken. The effort is not large and it does have large >>> payoffs. >>> >>> Duane >>> >>>> The breaking of forwards and backwards compatibility is managed by a >>>> model(by model I mean conceptual model, and not UML model) for how >>>> forwards >>>> and backwards compatibility works. Basically the second version of >>>> markup >>>> is, I would guess, forced on you by a model that limits >>>> extensibility, if >>>> you are using XSD for validation, then you will want to have the >>>> contexts >>>> with multiple context child nodes. >>>> Extensibility in the wild is often done via the use of namespaces, >>>> thus what >>>> one wants is a namespace handling model that follows the model which >>>> developers are most used to, which is non-essential namespaces to >>>> application x are ignored by application x, this allows developers >>>> to extend >>>> a type of xml dialect with new semantics relevant to them without >>>> worrying >>>> about breakage, unfortunately this is not the model that XSD is >>>> especially >>>> good at handling. >>>> finally when you talk about forwards or backwards compatibility I >>>> think that >>>> what one should be discussing is a versioning strategy, how should >>>> version >>>> 1.0 processors relate to version 1.1 instances that are bound to our >>>> namespace, in that case the general reaction is to say that in a >>>> version 1.0 >>>> instance read by a version 1.0 processor all markup in the target >>>> namespace >>>> must conform to version 1.0 markup, in a version 1.1 instance all >>>> markup in >>>> the namespace not conforming must be ignored, and it's subtree ignored, >>>> sometimes one extends the dialect by using a construct >>>> mustUnderstand, so if >>>> your first example was: >>>> >>>> <mydoc version="1.1" xmlns="http://mydoc.org";> >>>> <Contexts mustUnderstand="True"> >>>> <GeopoliticalContext> >>>> <Value> Canada</Value> >>>> </GeopoliticalContext> >>>> <SomeOtherContext> >>>> <Value>1234</Value> >>>> </SomeOtherContext> >>>> <NewVersionContext><Value>282738</Value></NewVersionContext> >>>> </Contexts> >>>> </mydoc> >>>> >>>> this should cause a mydoc 1.0 processor to fail because it >>>> mustUnderstand >>>> everything under Contexts, and NewVersionContext is an element >>>> introduced >>>> with version 1.1 >>>> The question is not if one version is more or less extensible than the >>>> other, they are both extensible, the question would be which makes >>>> for a >>>> better understood model for developers, users etc. I have my >>>> preferences, I >>>> think that the Contexts with multiple child context nodes is probably >>>> preferable in comparison to the other example, but that a well-defined >>>> versioning strategy and namespace handling model in the initial >>>> specification is how one handles extensibility and forward backward >>>> compatibility. >>>> Just my 0.02 kr. (I'm sorta getting screwed on the exchange rate here) >>>> >>>> >>> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]