Re: SV: [ubl] Further simplifications beyond subsetting

[stephen.green@systml.co.uk]

Hi Bryan

Mmm. I'm thinking it isn't constraint or detection that is the
issue with point #1
> 1. need to eliminate empty elements
- not so much the need to detect empty elements but the need
to actually eliminate them from the output. They get included
by default and XForms version 1.0 doesn't really cater for
the removal of the element from the output if it is empty; even
user-driven removal.

However, that is just a breach of what to me seems a minor ND
rule; the main issue is the multiplicity of namespaces and perhaps
too the use of import and include with multiplicity of physical
files.

I could imagine the need being addressed here by developers
but I wondered if UBL could be cleverer than that. Not so clever
as to confuse though. I really couldn't see this feature being
added to UBL's successor without first an initiative within UBL.

Subsetting can address the need for pruning the model but not
other aspects of the schemas. It doesn't seem though that the
change can be made to physical schemas without a change required
to instances since it doesn't seem possible to create a schema
in one file which validates the instances as they are. So an
augmentation seems to be required to UBL itself for it to work
with these other key emerging technologies.

All the best

Stephen Green



Quoting Bryan  Rasmussen <BRS@itst.dk>:

>
> Hi Stephen,
>
> I think such things as the requirement for no empty elements can be satisfied
> by a constraint check in xforms.
>
>
> Cheers,
> Bryan Rasmussen
> -----Oprindelig meddelelse-----
> Fra: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
> Sendt: 7. februar 2007 11:53
> Til: ubl@lists.oasis-open.org
> Emne: [ubl] 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
>
>