OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-dev] Simpler-Than-UBL Design Rules


Steve, 

Looking at this from the CAM end of the telescope - (not sure if that's
the fat or the thin end!)... 

CAM obviously gives you the ability to quickly rough out your
localization and create the context rules and use pattern. 

How to tie that back then into CCTS NDR?  Well I'm deep in the middle of
editing OASIS EML v5 schemas - and even with the power of OxygenXML
editor - there's a lot of back and forth - and like with UBL there's a
huge set of COMMON include object type definitions to be reconciled. 

Now in the CAM v1.1 - its actually a subset of the original CAM design -
what we moved out to non-normative section is the <Reference> section. 
This section is designed to tie into the CCTS NDR world - from the
simple XML content model. 

But we moved it out because there's a lot of flux still around this -
specificially in CEFACT on the CCTS xsd and registry persistence, and
the registry accessing via REST too.  Both of which we need to resolve
before we can add this back in to CAM v2.0 as a normative item (when we
get there!). 

Anyway - what <Reference> offers is a simple means to associate an item
in the XML to its definition in the CCTS - and hence inherit its
properties / content model.  Then of course local rules in the CAM
template can modify that contextually as needed. 

You will need to wait till CAM v2.0 to get all this - but - in the
meantime - have you thought about using AJAX based forms in lieu of
XForms?   I've been thinking about generating either the XForm or the
AJAX directly from the CAM editor - we believe that is highly doable -
given the information that is already in the CAM template about the
information model and relationships of the fields.  Right now all we
are doing is running your xsd scripts to do this - but those have to be
made manually ahead of time - this would be an auto-generate feature... 

Then the other cunning thought I had - was running the jCAM engine as
part of the form entry process - so this would be highly doable in AJAX
- where you go out to a jCAM web service and get back the validation
results...

Thanks, DW

"The way to be is to do" - Confucius (551-472 B.C.)

 -------- Original Message --------
Subject: [ubl-dev] Simpler-Than-UBL Design Rules
From: stephen.green@systml.co.uk
Date: Wed, February 07, 2007 6:55 am
To: ubl-dev@lists.oasis-open.org

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



---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]