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

[stephen.green@systml.co.uk]

Hi David

Thanks for this.

I would like to ask: Is there the ability in CAM to
cater for a full XPath statement? It's just that the
Editor seems to mainly have just parent and child,
not the whole ancestry of the node. That would be
an important gap for UBL as UBL seeks to fulfil the
requirement of certain codes and identifiers to be
specified specifically for the precise document
location (Ken calls it document context). e.g. a
a currency code might be restricted to home currency
for tax amount but not restricted for other amounts.
UBL 2.0 NDR is weaker for this than UBL 1.0 NDR as
the codes and identifiers are globally defined but
that is due to some problems with XSD and namespace
prefixes if not everything is global when one tries
to use certain means of derivation. The codelist
methodology makes up for this using Schematron so
it would naturally be approriate for context-aware
CAM to have the same ability.

I've thought a bit about using AJAX but that would
seem to be a backward step:

firstly, no advantage I'd have thought on the client
side as there is no assertion that the client forms
processor (browser only I should think with AJAX) has
a built-in means of validating against any kind of schema

secondly, no built-in facilities for avoidance of script,
declarative programming, framework for good practise,
or nice way of doing repeats

thirdly, the requirements of customisation and context
are such that it seems preferable to use schema-driven
code generation to allow changes to schemas (or models
if you prefer) to be rippled in a CASE-like way into
the form - not sure you can reliably do this with AJAX
as it seems you can with XForms.

fourthly, I've come across converters from XForms to
AJAX but not the other way so I'd prefer to start with
the XForms which * can * it seems be schema-driven and
optionally generate the AJAX or whatever - which might
answer some of the above to some extent (yet to look
into that thoroughly though)

All the best

Steve


Quoting "David RR Webber \(XML\)" <david@drrw.info>:

> 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
>
>