Re: AW: [ubl] Re: Next Version & Customization

[Tim McGrath <tmcgrath@portcomm.com.au>]

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