[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Further simplifications beyond subsetting
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]