[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Discussion of substitution groups
> > 1. control of extension and restriction > using the XSD derivation rules > is enforced by compliant tools That is not an advantage of substitution groups. O > 2. the XSD derivation provides a trail > - a trace back to the types > from which derivations were made > (helps with audit requirements, etc) 2a. compliant tools > provide a better, > richer experience to developers But the trail is the library itself as resident in the schemas from the different versions and the artifacts stored in the registry as UML profiles. > > 3. this is becoming a more ubiquitous > way to extend/restrict - audit > rules tend to expect financial software > to follow such ubiquitous > software designs and methodologies > (in my limited experience) Please provide specific audit requirements that are satisfied by substitution groups. It seems to me that you are saying that if I use substitution groups, then I am extending the types. Therefore I need specific audit rules that address this. > > 4. people are wanting XML to deliver > on the eXtensible bit (see ubl-dev) The extensible bit is in the vocabulary and how customizers use that vocabulary and our normative schema. Not in how we create our normative schema. > 5. software vendors are increasingly > investing in substitution group > support (hence 2a above and more) And Ford is building new cars, so does that mean I need to buy one? > > 6. this delivers on UBL's original > promise of polymorphic inheritance > (albeit at a price of a single rule > about sg's being dropped or qualified) I am still not convinced that this is a key aspect of UBL. There were two people who supported this concept - and they are no longer with us. > > 7. this buys into the benefits of using > global rather than local Sorry - I completely disagree here. Our discussions of global were centered around managing by both types and elements. > > 8. this best fits the OO development > practises (see JAXB) Not sure I understand this one. Our OO development is related to our modeling at the data level - not how we create the types. > I could go on... Please do. So far I don't see any specific technical reason that necessitates using substitution groups. Mark
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]