Re: [ubl-dev] Hybrid approach to local vs. global

["Stephen Green" <stephengreenubl@gmail.com>]

A few points have come to my mind:

1. the schema complexity itself seems to be one of two main remaining barriers
to adoption (thankfully I think openness by the TC to the need for
subsetting with
no change of namespace has removed the barrier of the model complexity)

2. the ATG2 schema design suffers from the same complexity issue but I'm not
sure whether to a greater or lesser degree

3. moving codelists out of the equation by allowing their validation with other
schematic techniques has helped with the complexity issue

4. CAM too takes the pressure off a bit by allowing other aspects of validation
and definition to be taken away from the purely XSD approach (thanks
David and Martin)

5. this leaves a question of: What artefacts does the world really
need the main standards
group (UBL TC + CEFACT ATG) to deliver besides the models?

a. I guess if other bodies will provide customisations and subsets and perhaps
using CAM and / or Schematron and / or Genericode to do so then maybe
the W3C XML Schema aspect is less a concern (but a little inconvenient
if it is complex)

b. I still think 'outside groups' might want to create other representations
(just as UBL TC has done with ASN.1) and the need for this is greater when the
schemas from the standards group are complex

c. following on from b, if the schemas are complex and folk 'outside' need to
simplify them and there is problem in doing so or a lot of simplification is
necessary leading to a greater degree of side effects, there is a
great 'risk' of
a breaking away from the schema and instance design desired by the committee

6. the very fact that a set of schemas can be generated with a different design
brings into question the importance of the design in the first place

6a. UBL already does something similar to what is proposed by issuing two
designs of schemas (no I mean ASN.1 and XSD) and does more by providing
for two designs of instance (ASN.1 and XML) so a further design of schemas
and a mapping is along the same lines

Alternatively
6b. why not just deliver the models, namespaces (I very much think there should
be a maximum of one per document type) and some suggested design rules
(more than one set) and maybe some non-normative schemas (like the ASN.1 ones
in UBL) - so all the schemas are non-normative and so are the design rules and
effectively so will be the exact formats of the instances (as with
UBL's ASN.1 and
XML dual compliance requirements)

6c. historically there was a need to create single schema sets to help bring
in uniform adoption into the equation and to fit the fashion in XML of
doing that
but now we are more mature we should be able to comply better with the CCTS
vision of model-level conformance as normative and so long as CCTS is complied
with in spirit, allow laxitiude about the need for implementation
level conformance
such as the XML or binary

6d. different tool sets are now more mature than when all this started and the
idea of forcing the tools to match the schemas is less acceptable, so 6c should
allow greater flexibility in adoption

Better leave it the - for now :-) - I'll be back! :-)

All the best

Stephen Green