Re: [ubl] Abstract type (was: Re: A Codelist Issue)

[Anne Hendry <anne.hendry@sun.com>]

I don't remember this explicitly being discussed but it was my 
understanding that only the issues were being raised (or we'd be there 
forever!), and that everyone that had a strong enough interest to object 
had done their homework and read the document.  This very explicitly 
appears in every version of the code list document going back as far as 
I have archived (right now to January) in many places - there is an 
entire section on the schema representation.  Step 1 at the start of 
section 4 (XML Schema Representation of Code Lists) says "Define an 
abstract element for inclusion in extensible schemas ...", then Step 4 
says to "Define an element that substitutes for the abstract type to 
enable usage in unextended schemas.".

This is slightly irksome about the objection to substitution groups as 
well.  I noticed the conflict on the use of substitution groups several 
weeks before the f2f and raised it in a clsc meeting as something we'd 
have to get ndr review of.  We discussed at the time that there was no 
other way to get the required functionality - or no better way.  Then at 
the start of the F2F I asked Mike (G) to do a pass over the cl document 
with an eye to ndr compliance and mentioned the substitution group use 
to him then.  We discussed the possibility of getting approval to use it 
in this instance, since there were several other places where the ndr 
mentions that other forbidden constructs that would be natural 
alternatives to substitution were noted as being possible exceptions for 
the case of code lists.  Actually, there are several instances where the 
ndr makes exceptions for code lists (eg. xsd:union) and Mike (correct me 
here if I'm overstating this, Mike) thought there was a good reason here 
to ask for similar dispensation.  Since I didn't participate in the 
smaller cl meetings during the rest of the week, I assumed this had been 
discussed there as well.  If it wasn't that's becuase I assume the issue 
Stephen raised was taking precedence, but regardless, we certainly had 
enough warning that this was the construct being used!  Its mention is 
throughout the document.

The real issue I see is not that ndr fobids it, but why, so if we can 
focus not on the rule, but the reason why this is not a justifyable use 
of these constructs if truly there are no other alternatives to provide 
functionality we feel is needed (and yes, I agree, the need is still not 
completely clear, but after listening to Sylvia and Marty I feel more 
stronly it is, as a real use case, similar to Stephen's use case for the 
presence of metadata in the instances) then we should udnerstand the 
risks vs benefits and what our options are in the face of requirements 
we hadn't heard of before, rather than just say 'we have a rule ...'. 
 I'm not advocating questioning every rule, but when something like this 
comes up that may really be the best alternative we should go a little 
deeper on it, I think.

Although I don't recall your final presentation details to the plenary, 
given this is so integral to the solution, and discussed in so much of 
the document, I would have expected you to have it in your final diagram 
you presented to the plenary, yes.

-A

jon.bosak@sun.com wrote:

>[Eduardo.Gutentag@sun.com:]
>
>| > We did in fact discuss the use of substitution groups and abstract
>| > types for code lists in Washington, and we did come to an
>| > agreement among the people attending that we could live with
>| > making an exception to the NDRs for code lists to allow these
>| 
>| but no discussion took place regarding an exception to the rule
>| that types cannot be abstract, which I understand from previous
>| emails is also part of the proposal.
>
>Unless I'm thinking of something else, the abstract type mechanism
>was in Marty's paper, and no one expressed a problem with it.  I
>believe that this was even contained in the diagram I put up in
>front of the closing plenary when we discussed how the proposed
>solution was going to work.
>
>Does anyone remember this differently?
>
>Jon
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
>
>  
>