Simpler-Than-UBL Design Rules

[stephen.green@systml.co.uk]

Sending again, doesn't seem to be getting to the list:
>
> 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