[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] further design considerations for 2.0 (prototype '-sdg-2' attached)
From: Stephen Green
[mailto:stephen_green@seventhproject.co.uk]
Sent: Monday, April 25, 2005 8:52 AM To: ubl@lists.oasis-open.org Subject: [ubl] further design considerations for 2.0 (prototype '-sdg-2' attached)
Greetings
> The first step, already
demonstrated, was to show that > there are problems
introduced with the local declarations > of IDs and Codes in
1.0, hence the decision to remove > this design aspect by
moving to a 2.0 major version. > The main problem
introduced with these local elements > was in the fact that
the instances for 1.0 would, if a > minor version used
polymorphism with imports of these > schemas, require a
change to the local elements from > default namespace
without prefixes (e.g. in:Invoice/ID) > to element names with
prefixes (e.g. in:Invoice/in:ID) for > tehm to be valid
against the new schemas. This is > considered to be an
undesirable compromise of backwards > compatibility in one sense of our understanding of it.
>
> I've tried to test this
a bit further by making the change > to the IDs and Codes
and then using the substitutionGroup > mechanism in subsequent
prototypic minor versions > and I've found that
this change may not quite be enough. > To allow minor version
schemas to correctly validate the > major version instances
with only minimal changes (e.g. just > schema location and the
like) to the instances it appears > (as the attached
prototype demonstrates) that we have to > make two further
changes to the document schemas: > Firstly there are in
UBL 1.0 some BBIEs declared in the > document schemas rather
than in the common (CBC) > schema and these would
have to be moved to CBC; > Secondly there are in
UBL 1.0 some ABIEs declared in > the document schema and
these too would have to be > moved to the common schema (CAC).
> > 1. Moving two Codes,
ReasonCode and IdentificationCode > to the common module
(CBC) there may need > to be a renaming of the
elements since the names are > far less specific in
1.0 than the datatypes which > are tied to quite
specific codelists (namely > AllowanceChargeReasonCode
and CountryIdentificationCode). > There is also a general
principle here to which we'd > need to adhere more in
modeling with this new design: > that the more specific
the datatype (e.g. a more > specific codelist),
the less generic should be the element > name.
>
> 2. We need
to clarify whether an ID element should > have a complexType named IDType or IdentifierType
> There may be other
improvements to such naming > rules we'd like to make
too (some type names seem > too arbitrary generally).
> > 3. Does an xxxxCode
element have to have a > complexType name
xxxxCodeType or is just CodeType sufficient? > Is this covered by NDR?
> 5. The NDR and other
schema module diagrams will need > reworking since the
patterns of imports will change. > I hope the attached prototype will help with this.
> > 7. If the
reasoning about the need to define all of the > document BIEs in CAC
and CBC schema modules are accepted > this may need to be explicit in the NDR
> > 9. There will likely be
frequent occasions when a type to > be extended was not
explicitly declared in the previous version > (if only the types we
changed in that version were explicitly > included, as required
for modular rather than blanket revisions). > This does then require
(as in the 2.2 schema of the attached > prototype - Delivery
example) the import of earlier version > schemas such as the
previous major version and with it the > older namespaces and
suitable prefixes. This then means that > we are likely to need
rules to define separate suitably named > prefixes for each
version and these should ideally include > some indication of the
version number (perhaps even for the > major version). For example, I have used cac2-0, cac2-1, etc.
> > 10. I do not forsee
problems incorporating the ATG2 CCTS > schemas into the
prototype (though I haven't done so here) > - see previous mail
with such a design prototyped. But the > complexities of the
polymorphic versioning may be quite a > challenge, it seems, to
keep it in step with the ATG2 design - > mainly
considering possible namespace aspects (as seen > in point 9
above). This concerns whether instances with the > necessary multiple
namespaces/prefixes for the UBL design > instances could
be catered for in an ATG2-type set of schemas. > Whether instances valid
to the ATG2 schemas could have > the necessary
complexity of namespaces to validate against > corresponding UBL
schemas is what seems an increasingly > challenging prospect as the real details are considered.
Mark
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]