[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Abstract type (was: Re: A Codelist Issue)
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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]