ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ubl-ndrsc] schema version as context classifier
- From: "Burcham, Bill" <Bill_Burcham@stercomm.com>
- To: ubl-ndrsc@lists.oasis-open.org
- Date: Tue, 06 Nov 2001 13:17:53 -0600
(what follows is a bit of a ramble --
apology in advance)
Has there been any discussion of the
possibility of treating schema version as yet another context
classifier?
In exploring the decision space for
this issue (from the Oct 31 NDR SC minutes):
Issue: Should namespace
names contain version information, or should versions be indicated in some
other way?
...I'm running into some questions I'd like
feedback on.
We have this goal (from the Nov 1 CDA SC
minutes):
Goal P: We want to allow communities of
users to create their own "standard customizations". Assuming that our
methodology and tools are robust enough, this could be viewed as allowing them
to persist sets of contextualized schemas derived from UBL.
That goal, taken with this statment (from
the same minutes):
In a sense, core components are just BIEs
that have the defaulted context driver values.
Leads to a model in which both core
components and contextualized CC's a.k.a. BIE's may be versioned. It is my
understanding that previously the CC folks may have talked in terms of
versioning CC's and that BIE's would be generated from those. Now we are
talking about allowing direct revision of contextualized BIE's. Those
BIE's might not have been machine-generated from CC's.
If the purpose of namespaces is to
disambiguate short (element and type) names, then if I begin reasoning from the
side: "yes namespaces should contain version information", then doesn't it
follow for similar reasons that our namespaces should also include context
classifier values. Seems like that path leads to madness...
Imagine I've got some BIE, freshly
reverse-engineered from xCBL. Let's say it's for
AdvanceShippingNotice. Our colleagues have scrubbed out most of the
context-dependency, but it's just too tedious for them to go all the way, so
they leave in dependencies on region.
- could that ASN BIE with a contextual
binding for region be part of our "normative" product?
- if so, then what namespace should that
thing be defined in?
- bear in mind that we may want ASN's with
other region bindings
- bear in mind that we may want to
revise this ASN
All this sounds really hard, so I won't feel
at all put off it people just tell me that this is out of scope. On the
other hand, if it is in scope, then I think we might want to treat "version" as
"just" another context classifier. That normalizes it with respect to
CDA.
Once version and other context categories
are normalized we are still left with the namespace question. At that
point it seems to me that you want neither version nor any other context
information in your namespaces right? Without version and other context
classifiers in the namespace we will need other means to express those
values.
How do we envision communcation of this
information from the site of processing logic (e.g. a style sheet) to some sort
of UBL support system (that can lookup/construct) root schemas? URL's are
certainly sufficient to support encoding all this stuff so we could specify a
schema resolver component that would take this monster URL (containing all the
context and BIE info) and produce it. Does this world view simplify the
original question? (can anyone still remember the original question
;-)
-Bill
469-524-2164
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC