[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" xsi:noNamespaceSchemaLocation="PriceList-STUDR-UBL-CatalogueSubset-v0-2.xsd"> <cbc.UBLVersionID schemeID="normalizedString">normalizedString</cbc.UBLVersionID> <cbc.CustomizationID schemeID="normalizedString">normalizedString</cbc.CustomizationID> <cbc.ProfileID schemeID="normalizedString">normalizedString</cbc.ProfileID> <cbc.ID schemeID="normalizedString">normalizedString</cbc.ID> <cbc.IssueDate>1967-08-13</cbc.IssueDate> <cac.ProviderParty> <cac.PartyIdentification> <cbc.ID schemeID="normalizedString">normalizedString</cbc.ID> </cac.PartyIdentification> ... 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 customization. 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]