← Prev in month ← Prev in thread

[ubl-ndrsc] schema version as context classifier

From
Burcham, Bill <>
Date
2001-11-06T19:20:22+00:00
ID
Thread
[ubl-ndrsc] schema version as context classifier
(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
← Prev in month ← Prev in thread