[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] schema version as context classifier
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC