OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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]