Re: [ubl] rewriting schemas

["Stephen Green" <stephen_green@seventhproject.co.uk>]

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
>