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: 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