[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Hybrid approach to local vs. global
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]