Re: [ubl-dev] Re: Code list extensibility and substitution groups

[Duane Nickull <dnickull@adobe.com>]

Jon:

Apologies - several of us couldn't resist taking a shot at CAM.  You are 
right and we should follow ocCAM's Razor - "one should not increase, 
beyond what is necessary, the number of entities required to explain 
anything".  Seems fitting, doesn't it ;-)
http://pespmc1.vub.ac.be/OCCAMRAZ.html

The code list issue is a serious one and I do have one question about 
determinism in this context.  Does this primarily refer to the fact that 
any extensions to the code lists themselves cannot change in structure, 
only the enumerated sets themselves can change?  Or does it imply a more 
sinister pre-requisite knowledge of the entire enumerated set of values 
AND the structure and both may be subject to substitution?

I do not see how you can both offer extensibility beyond that while 
still preserving inter operability.  I think that looking at what 
developers will have to do to access the code list values is important 
in order to fully grok the complexity of the problem. My observation 
would be to strictly define the logical data model and XML expression 
for structure of code lists in order to allow deterministic statements 
to be evaluated to retrieve code list values and marshal those into 
objects during the parsing process.  For example,you could define an XML 
structure that will always give you a List object containing all the 
values for codes.  The java could be written like this:
// parsing the schema for enumerated values
    public InputStream[] getDataElementStreams() throws Exception {
        List codes = 
this.currentElement.getChildren(CodeValueElement.SOME_FINAL_TOKEN_HERE);
        InputStream[] ret = new InputStream[codes.size()];
        for (int i = 0; i < codes.size(); i++) {
            try {
                ret[i] = new 
DataCodeElementRef((Element)codes.get(i)).getInputStream();
            } catch (IOException e) {
                throw new AssemblyException("You wrecked UBL codes 
forever....", e);
            }
        }
        return ret;
    }

This would allow a schema parser to interpret the entire substitute code 
list as long as the structure rules were followed.  That is about as 
deterministic as you can get IMO.

The GoC had some really compelling use cases for conditional validation 
of code set values based on qualifiers.  The ability to support their 
use case was not present in the current draft of W3C schema however some 
issues were fixable by defining a better object model before expressing 
it in XML (although I wouldn't want to start yet another elements vs. 
attributes holy war).

I did see some cases where there is ambiguity in the UBL code list 
specification.  For instance, what is the difference between a code list 
identifier, code list name identifier, code list URI and a code list 
name text?  The URI to me is a specialized instance of identifier  - I 
ponder why more than two are needed.

If you allow changes to the structure, you are doomed.  No one can 
effectively process XML if the structure itself is compromised from 
instance to instance - that is why we developed DTD's, schemas etc. in 
the first place, isn't it??

My $0.02 CAD worth (despite WIlliam thinking the currency is doomed)..

Duane

jon.bosak@sun.com wrote:

>Hello folks,
>
>Amusing as the CAM discussion may be, it's not providing the UBL
>TC with the information it needs to make an informed decision on
>the subject of code list extensibility.  Please do us a favor and
>either take the CAM mail somewhere else or at least put it under a
>different subject heading so that the rest of us can filter it
>out.
>
>There's one week left in the time allotted to get the input of
>people who care about code lists.  I had been given to understand
>that there were people out there passionate about code lists and
>other people (not necessarily the same ones) passionate about
>substitution groups; this is their one and only chance to
>influence the direction of UBL in this regard.  If those people
>don't speak up now, they will certainly get no sympathy if things
>don't go the way they want.  See the announcement from a week ago:
>
>   http://lists.oasis-open.org/archives/ubl-dev/200502/msg00006.html
>
>A key question needing resolution is whether code lists in UBL 1.0
>can be changed with only minimal effect on the other schema
>modules.  Opinion so far in this discussion (such as it is) seems
>to incline to the view that it can't.  Does anyone disagree with
>that?  If so, please exhibit the simple solution.
>
>Jon
>
>  
>

-- 
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Adobe Enterprise Developer Resources  - http://www.adobe.com/enterprise/developer/main.html
***********