[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] rewriting schemas
Bryan This is now scheduled for review (between now and September). Not everyone has accepted the need to use this particular means to provide versioning. However, for customisation the rule does not strictly speaking apply and UBL's NDR was designed on the principle that it would provide for this kind of polymorphism with XSD derivation. It just happens that when, in April, our ad hoc working group looked at how this could work, the substitution group (non-abstract) methodology was the only means that could be demonstrated as valid. It works too for versioning but versioning is the main use for which an agreement is still being sought. For customization we do have an unfulfilled promise to outline a working mechanism (due, if at all, by the end of October) but in the meantime the 'how' is left to the customizing party, outside of UBL. Admittedly there are other methods for customizing (at least one example already exists in production) than to use just XSD derivation, imports and the non-abstract substitution groups with elements. But I don't see anything wrong with encouraging customizers to follow the approach we've so far most thoroughly researched, proven and most strongly recommended. Doing so would probably preserve the most interoperability across the board, I think. It may be especially important when seeking to keep customisations updated in line with minor versions (if the same approach is used for these): as yet I haven't seen any demonstration of any alternative approach working for customisation of a minor version but I have demonstrated that the above approach works with this. All the best Stephen Green ----- Original Message ----- From: "Bryan Rasmussen" <brs@itst.dk> To: "'Stephen Green'" <stephen_green@seventhproject.co.uk> Cc: <ubl@lists.oasis-open.org> Sent: Thursday, July 07, 2005 2:53 PM Subject: SV: [ubl] rewriting schemas > Hi Stephen, > > I think it would be reasonably useful. One thing though is from the NDR > > http://www.oasis-open.org/apps/org/workgroup/ubl/download.php/13200/NDR-2005 > -06-22.pdf > > 7.3 xsd:substitutionGroup 2046 > The xsd:substitutionGroup feature enables a type definition to identify > substitution 2047 > elements in a group. Although a useful feature in document centric XML > applications, 2048 > this feature is not used by UBL. 2049 > [GXS5] The xsd:substitutionGroup feature MUST NOT be used. > > I was under the impression that the current argument was that we were going > to end up using either substitutionGroups or Redefines? > > > > -----Oprindelig meddelelse----- > Fra: Stephen Green [mailto:stephen_green@seventhproject.co.uk] > Sendt: 7. juli 2005 15:37 > Til: ubl@lists.oasis-open.org > Emne: Re: [ubl] rewriting schemas > > > Hi Folks, > > The examples of customization I posted > at http://lists.oasis-open.org/archives/ubl/200506/bin00010.bin > were not using actual UBL 1.0 schemas. > I wonder if it would help to produce > a set of examples based on UBL 1.0. > Would this be valuable? > > All the best > > Steve > > ----- Original Message ----- > From: "Bryan Rasmussen" <brs@itst.dk> > To: <ubl@lists.oasis-open.org> > Sent: Thursday, July 07, 2005 1:39 PM > Subject: SV: [ubl] rewriting schemas > > > > hmm, I guess this was the rule I was thinking of: [NMS3] UBL namespaces > MUST > > only contain UBL developed schema modules. > > > > -----Oprindelig meddelelse----- > > Fra: Bryan Rasmussen > > Sendt: 7. juli 2005 14:20 > > Til: 'ubl@lists.oasis-open.org' > > Emne: [ubl] rewriting schemas > > > > > > > > I can't find this in the UBL-NDR-1.0.1, although I seem to remember that > it > > was there at one point, is there a rule specifically against taking the > UBL > > schemas and rewriting one of the elements in there to have a different > > cardinality, although still within the cardinality of the original schemas > > (as one example of a change that would not have any meaningful effect on > > validation)? > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your TCs in > OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. You may a link to this group and all your TCs in > OASIS > > at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]