[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [ubl] Re: Next Version & Customization
i support Michael's view on this. We should be aiming to demonstrate how customization works. i also agree that we cannot just customize the schemas - we have to have customized models as well. how else can we maintain the link between them? Michael Dill wrote: >Dear All, >there is one other aspect, which could become important also for such a >decision: > >This is the customization and the customization concept. > >- As far as I understand, there is not yet a concept telling people, how to >extend, restrict, specify UBL data. >- Also I'm not aware of any decision whether this concept starts on a model >level or on a schema level or both. >- It will be important to see how an interaction with users and their spec's >re any further development of the UBL standard data will be organized. > >A major new version of UBL should take notice of the lessons of >customization. Even, if the UBL TC statement would be that the customization >by end users did not effect the concept of the further development and >maintenance. That's why I'd prefer first to have experience with any >customization (rules). > > >best regards, >Michael Dill > > >-----Ursprüngliche Nachricht----- >Von: jon.bosak@sun.com [mailto:jon.bosak@sun.com] >Gesendet: Freitag, 8. April 2005 03:49 >An: ubl@lists.oasis-open.org >Betreff: [ubl] Re: Next Version > > >[MCRAWFORD@lmi.org:] > >| Jon wrote: >| >| What do we think about calling the next release "UBL 2.0" >| rather than "UBL 1.1" >| >| My comment - are we prepared to wait an additional 3-6 months to >| do everything necessary for a major release? > >The suggestion is to take what we were going to release at the end >of the year and call it "2.0" rather than "1.1". It could be >argued that what we've agreed to do in implementing the (highly >beneficial) submissions we're getting is going to be hard to >accomplish in the time we've scheduled, but changing the name >doesn't have much to do with this. The OASIS TC process does not >distinguish between major revisions and minor revisions. > >The one difference the name change would make to our workload >would be in allowing us to align with the noncontroversial aspects >of the ATG NDRs earlier than we would otherwise be able to. While >adopting the ATG CCT modules (for example) would entail some >amount of work, I think we could limit the impact by simply >declaring any change that looked like a lot of trouble to be out >of scope for this release. > >[mark.palmer@nist.gov:] > >| As one who is working on building cooperation and convergence >| between UBL and UN/CEFACT, changing the label for the next release >| from 1.1 to 2.0, will add some confusion to the ongoing >| discussions and the common understandings already established. > >Yes, it would require some explaining, but the people we're >talking about seem to have already made the transition from "1.0" >to "1.1" without serious injury. I would think they'd be happy to >hear that this name change will allow us to reduce the number of >differences between OASIS and UN/CEFACT NDRs earlier than >forecast. It wouldn't resolve the big local/global issue, of >course, but I doubt that anyone involved in the UN/UBL discussion >would accept a solution associated with the number 2 but reject >that same solution if associated with the number 3. > >The important thing as far as I'm concerned is that implementing >the noncontroversial changes now while the installed base is still >small will save our users a great deal of trouble going forward. > >[gkholman@CraneSoftwrights.com:] > >| 2.0 can certainly add to the set (I'm not advocating we not >| increase the package), but 1.1 will give us a "more complete set" >| than we had in 1.0, and may help to give the impression that we >| are "finishing up" the first release. Then we can launch into a >| 2.0. > >Don't kid yourself about the size of this beast. Implementing the >joint European process model we requested will roughly double the >size of the spec. I believe that this is the best thing that >could possibly happen to both UBL and its users, but calling the >result a minor revision doesn't really do justice to it. We're >looking at a pretty big jump forward on the content side no matter >what we do with the NDRs. > >[mhb@itst.dk:] > >| My comment - the process around a minor version release put >| restrictions on the changes that could be done to the existing >| messages. A major version release would have allowed for more >| flexibility - meaning that the messages would not necessarily have >| to be backwards compatible. > >The kind of changes we're talking about should cause relatively >minor disruption compared to what we'll face later on if we wait >another couple of years. Of course, people who've based their >implementation on an older version might not care so much about >this. :-) > >Jon > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160 DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services (coming soon from MIT Press) http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]