<Quote>
Your suggestion mirrors the approach CAM is
using
Joe,
Your suggestion mirrors the approach CAM is using -
in that CAM allows
you to associate UID values and sub-version those -
accordingly
(sub-versioning is critical BTW - allows notion of "use latest
always"
as well as calling out descreet point items - and ebXML
registry
supports LID for this).
However - no re-assembly from parts
is needed - the CAM approach
overlays directly on existing artefacts - which
is a big plus - because
you can version existing instances and schemas
in-situ without having to
change them or the method(s) you use to complete
them.
Likewise the UID references can optionally point to semantic
content
stored in the ebXML registry - either as XSD fragments - or using
the
XML noun semantic storage format devised for this purpose. Or -
you
can use standalone techniques in the template - without needing
the
registry.
Clearly you can also use the registry to directly link
UID reference to
namespace item labelling too - providing means to bridge
between both
needs. This would be a nice way to group UIDs belonging to
a ns
release.
So - essentially the versioning mechanism becomes an
overlay layer
through the use of the CAM template.
Thanks,
DW
p.s. BTW - this clears this up for me - I thought you were wanting
to
use the registry to store information about the namespaces - eg a
CMS
function!! That is clearly another very obvious use
case...
-------- Original Message --------
Subject: RE:
[ubl-dev] Low level versioning
From: "Chiusano Joseph"
<chiusano_joseph@bah.com>
Date: Wed, May 17, 2006 11:04 am
To:
"David RR Webber (XML)" <david@drrw.info>, "Fraser
Goffin"
<goffinf@googlemail.com>
Cc: "UBL-Dev"
<ubl-dev@lists.oasis-open.org>, "XML-Dev Mailing
list"
<xml-dev@lists.xml.org>
This seems like an opportune time
to mention the "Namespace Manager"
feature proposal[1] that I sent to the
OASIS ebXML Registry TC in
January 2002 (I try to bring it up about once or
twice a year, to remind
folks that it's still out there;)
With such a
feature, one could register in an ebXM Registry
implementation the namespace
that each construct
(element/attribute/datatype) is associated with, as well
as the
constructs themselves, with an association between constructs
and
namespaces. Then, if a schema were to be constructed (assembled)
at
design time using a UBL schema (perhaps retreived in its entirety, as
a
"blob" so to speak) and custom (non-UBL) constructs, the
resulting
schema can reflect the proper versions of the constructs via
their
namespaces.
I've just set myself an electronic reminder to bring
this up again
sometime, somewhere, this November ;)
Joe
[1] http://xml.coverpages.org/namespaces.html
(search
on "namespace manager", or go right to
http://lists.oasis-open.org/archives/regrep/200201/msg00061.html
to see
the archived proposal)
Kind Regards,
Joseph
Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW, Suite
1100
Washington, DC 20005
O: 202-508-6514
C:
202-251-0731
Visit us online@ http://www.boozallen.com
-----Original
Message-----
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Wednesday,
May 17, 2006 10:12 AM
To: Fraser Goffin
Cc: UBL-Dev; XML-Dev Mailing
list
Subject: RE: [ubl-dev] Low level versioning
Fraser,
I very
much believe versioning is needed to the element/attribute level
in an
operational environment and using OASIS CAM this is very much
attainable /
essential.
Therefore I'd pro-offer - if this is a key business need -
then you can
use CAM templates to overlay this fine level of detail over the
base UBL
schema between you are your partners.
As for UBL itself -
since the version only changes periodically - on a
major release schedule -
then the course grained ns approach is
probably
sufficient.
DW
-------- Original Message
--------
Subject: [ubl-dev] Low level versioning
From: "Fraser Goffin"
<goffinf@googlemail.com>
Date: Wed, May 17, 2006 10:00 am
To:
UBL-Dev <ubl-dev@lists.oasis-open.org>, "XML-Dev Mailing
list"
<xml-dev@lists.xml.org>
There has been some recent
discussion in my organisation as to whether
there is a need to provide verion
information for each element/aggregate
in our standard data
model.
Currently versioning is only visible to implementers on the
business
transaction level schema (namespace), that is, individual parts are
not
individually versioned.
Does UBL provide individual version
information for each business
entity, and are each of these visible when
entities are combined to form
a business transaction ?
I have a
feeling that traceability to the core data model needs to
reflect version,
but I remain to be convinced about whether it is
necessary at this level at
run-time.
All opinions
welcome.
Fraser.
---------------------------------------------------------------------
This
publicly archived list supports open discussion on implementing the
UBL OASIS
Standard. To minimize spam in the archives, you must subscribe
before
posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately,
using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee
homepage: http://www.oasis-open.org/committees/ubl/
List
Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join
OASIS: http://www.oasis-open.org/join/
---------------------------------------------------------------------
This
publicly archived list supports open discussion on implementing the
UBL OASIS
Standard. To minimize spam in the archives, you must subscribe
before
posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately,
using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee
homepage: http://www.oasis-open.org/committees/ubl/
List
Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join
OASIS: http://www.oasis-open.org/join/
---------------------------------------------------------------------
This
publicly archived list supports open discussion on implementing the
UBL OASIS
Standard. To minimize spam in the
archives, you must subscribe before
posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately,
using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee
homepage: http://www.oasis-open.org/committees/ubl/
List
Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join
OASIS: http://www.oasis-open.org/join/
