All,
I agree with the general conversation that demonstrating the customization
model of UBL is an important validation of its design. I don't know about the
timing or version at which this is done, but I think its valuable and
important.
Also, it is preferable to support customization of the data model as well.
I suggest that once we validate the schema customization method, it should be
straightforward to abstract that method back to the ubl models leaving behind
schema specific jargon and concepts.
Cheers,
Marty
Burns
President
Hypertek, Inc. for NIST
14624 Country Creek
Lane
North Potomac, MD 20878
P +1(301)315-9101
F +1(301)217-9503
C
+1(301)257-9101
E burnsmarty@aol.com
In a message dated 4/8/2005 8:15:15 P.M. Eastern Standard Time,
tmcgrath@portcomm.com.au writes:
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
---------------------------------------------------------------------
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
|