Further simplifications beyond subsetting

[stephen.green@systml.co.uk]

I've just sent the message below to the ubl-dev list but
maybe it is something UBL TC might consider. Basically,
I'm just really pointing out that as well as a requirement
for business applications which is solved with subsets
there may be a requirement for software in general and
standards such as XForms which is best solved by creating
transformations to and from documents conforming to a
simpler NDR. I've suggested this simpler design in terms
of the existing NDR. It would amount to another aspect of
customization which maybe hasn't received much consideration
openly but which might be just as important as subsetting.

Best wishes

Stephen Green


Hi Folks

I've been looking at writing a schema for the file I sent recently
for David Lyon's work and both that and my work on XForms for UBL
has made me realise we probably want a version of UBL with a
simpler schema design but the same model.

I started with David's xml for a price list, mapped it to UBL, mapped
that back to the original and added a few things UBL interop would
require (not quite in that order) and ended up with some xml which
was simple, mapped nicely to a subset of a UBL document and was
quite readily handled in a primitive version of XForms. The need for
a CAM template to support the pricelist xml and also one to support
the corresponding UBL subset was quite apparent. What was then
the next step was to cater for software such as XForms which needs
a not-too-complex W3C XML 'XSD' schema.

So now I'm looking at producing and have produced in draft an XML
XSD schema for the pricelist BUT   it has to be a lot simpler than UBL
2 NDR dictates, so it seems. In short I seriously doubt that XForms,
for instance, will be able to support (XForms version 1) the UBL 2
NDR in its present form. Two factors are:
1. need to eliminate empty elements
2. apparent need for validation with a schema with, if I read the
XForms spec correctly, just one namespace (plus I anticipate client
side validation requiring single module schemata too but there I
might be pleasantly surprised)

Conclusion: the most obvious answer (short of moving the mountain
which might be an alternative answer but make take longer) is to
produce some naming and design rules for a simplified but UBL-like
subsetted document type.

It might look like this

1. single physical file, no imports or includes
2. single namespace
3. UBL rules for element and complex type naming (optional rule)
4. all global element definitions
5. all global complex type definitions
6. creation of complex and simple types for reusable datatypes based  
on those of ATG2/UBL
  but defined in the same namespace as the above and within the same  
module/physical file
  (CCTS-compliant qualified datatypes but without any imports or  
external namespaces)

This would then be mapped to UBL-proper subsets (perhaps at model level) and
the conformant xml files could be translated to UBL files and back  
after client-side
or after server-side validation based on the above.

The codelist validation methodology would also need to be adapted but  
maybe (guessing)
the existing methodology could be used after the transformation and  
primary XSD validation.

I'd dub this NDR STUDR ('Simpler Than UBL Design Rules') but call it  
what you like :-)

Any thoughts on this?

All the best

Stephen Green