Wow, lots of juicy stuff to think about. My responses, at least equally as
rambling...
At 01:17 PM 11/6/01 -0600, Burcham, Bill wrote:
>(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.
Note that allowing someone *else* to persist schemas doesn't necessarily
suggest that it's our probably how *they* identify and version
them. However...
>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.
I think that in the UBL world, it's easier to simply assume that UBL
constructs *are* BIEs (with perhaps defaulted context drivers). I
personally think that we should reserve "core component" talk only for the
material where we explicitly map/link our BIEs back to the ebXML core
components. (But I don't know that the TC has achieved consensus on this yet.)
>Now we are talking about allowing direct revision of contextualized
>BIE's. Those BIE's might not have been machine-generated from CC's.
Right. They will likely be hand-crafted by the TC based on xCBL, with
mappings back to ebXML.
>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.
The simplifying assumption that I made when I presented to the Library
Content SC was that we will *definitely* deliver on the
defaulted-context-driver versions of the BIEs for Phase 1, and we will
*possibly* deliver on some consistent set of contextualized BIEs in that
same timeframe, because xCBL might already have a pervasive contextual
flavor that we can leverage.
If people buy this, then it certainly points to needing versioning for
contextualized stuff as well as generic stuff...
> * 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.
What is being versioned -- the generic UBL as a whole, its canonical
context stylesheets for particular context driver profiles, both, something
else? I'm confused (but that won't stop me from pressing on :-).
>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 ;-)
I could imagine a URL query that conveys XML context driver profile
information. Let me spin this out a little bit.
First, I keep using the term "context driver profile", which I made
up. What I mean is a particular pattern of context driver values that
describe a particular business situation -- one of the slots in that
n-dimensional shape. (You could picture some of these slots, if they're
particularly common, getting named something mnemonic.)
I've been imagining that we'll have an XML format for conveying a profile,
something like this (though I know this is too simple):
<ContextDriverProfile>
<Geopolitical>U.S.</Geopolitical>
<BusinessProcess>...</BusinessProcess>
...
</ContextDriverProfile>
I don't know if an XML expression of this is really needed, but it would
help me to clear my head if we could have a normative schema for it...
There are various ways one could package this up as a URL query. You could
even binary-ize it (sort of like SAML is doing with its encrypted URL
artifacts that represent XML-based authentication structures).
If there were a driver called <UBLVersion>...</UBLVersion>, what would it
mean? Would it mean the generic version of UBL to start with in a
transformation? Does it mean the version of the context stylesheet that
should be retrieved for this particular profile?
Eve
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ sun.com