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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

Subject: Customizing where 'Simpler-Than-UBL' (STU) is needed

Greetings UBL TC, UBL-DEV, (sorry for cross posting)

I just got to a fairly stable state with a customization of
the UBL Catalogue for an opensource price list product. After
making a schema as previously mentioned with zero namespaces
(or at most one) and just one schema file I went on to
customise the Catalogue proper UBL schema files too. Both
can then be used but I made the single-file schema more like
the UBL proper schema with closer to identical instances by
starting the element names with 'cbc.' or 'cac.' as below

  <?xml version="1.0" encoding="UTF-8"?>
  <Catalogue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  	<cbc.ProfileID schemeID="normalizedString">normalizedString</cbc.ProfileID>
  	<cbc.ID schemeID="normalizedString">normalizedString</cbc.ID>
  			<cbc.ID schemeID="normalizedString">normalizedString</cbc.ID>

It isn't ideal (much better if I could somehow use the prefixes with
just one namespace but that seems to be treated as invalid in the
instances you have with UBL's schema design). It does work so far
though and a simple transformation both to and from UBL proper
instances is made possible while allowing validation against a
necessarily simpler schema. Reiterating:- that's a schema with no
more than one namespace and no more than one module/physical file.

I attach a copy of this baseline package with
1. custom UBL schemas (note the simplified qualified datatypes)
2. single file schemas (STU, STUDR)

There are corresponding view only XForms thrown in for those who
have an XForms viewer (try Firefox 2 with XForms extension, say).

CAM would be used to formally and more properly define the UBL

All the best

Stephen Green

Quoting stephen.green@systml.co.uk:

> Forwarded from ubl-dev, just to show what I might have
> to do with UBL to get it to work nicely with certain
> emerging technologies. Subsetting does not seem to be
> enough and it looks like (yet to be really sure of it)
> customization of the actual xml design may be necessary
> in these cases.
> All the best
> Stephen Green
> Quoting Stephen Green <stephen.green@bristol.gov.uk>:
>> Hi David
>> What might persuade me completely would be a Standardisation
>> of the AJAX configuration xml files you mention. But then maybe
>> XForms could be seen as a first step in that :-)
>> Many thanks for these very informative points.
>> I still hope the matter stays open about what AJAX, XForms and the
>> like can cope with in a browser (or equivalent) environment, or, for
>> that matter, in an open office environment - as regards XML validation
>> capabilities. This is in view of the possibility that there is a strong
>> need for artefacts with the UBL model but much simpler schemas.
>> Below is an example of what I'd think we'd be looking for (in this
>> case for the simplified price list as a subset of Catalogue, extendable
>> of course to cover more of Catalogue type as and when necessary):
>> They're a bit long, apologies. The advantage over just extending
>> and extending the home-brewed pricelist schema is that using the
>> 'simpler than UBL' one allows us just to keep adding further simplified
>> UBL elements and types as necessary with a simple transformation
>> to and from UBL-proper which amounts to a simple algorithm rather
>> than mapping and that means no change to some of the software
>> such as the stylesheet(s) required for the transformation to and
>> from UBL.


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