OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

(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.
  1. could that ASN BIE with a contextual binding for region be part of our "normative" product?
  2. if so, then what namespace should that thing be defined in?
    1. bear in mind that we may want ASN's with other region bindings
    2. 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 ;-)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC