[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Customizing where 'Simpler-Than-UBL' (STU) is needed
Perhaps, Ken, it would be different when it is all just different BBIEs for a common set of core components. This then would be a context specific implementation of the same BIEs and CCs. CCTS's harmonization and conformance emphasis is on the model rather than the implementation in XML. But I agree, this isn't strictly what UBL might decide to define as a customization, but I thought that decision hadn't yet been made. I personally think such decisions where possible should be made, preferably, in the light of real implementation experience - emphasising usability of the rules decided. The breach here is not with the UBL model or the BBIEs and CCs but with the NDR. I don't see a problem, in terms of UBL as an implementation of CCTS (or a standard soon to be merged with CEFACT's work), with alternative NDR implementations of the same BBIEs and CCs. I think that is the whole essence of CCTS. But yes it isn't UBL in the sense of UBL's current specifications, nor does it pretend to be. But it does depend on real life implementation requirements for which I believe CCTS is sufficient and so are the BBIEs of UBL but not yet the NDR. It's essentially an alternative but adequately interoperable NDR essential for certain contexts. I do apologise as I realise I'm asking a lot and taking a big chance of outright rejection by UBL, though perhaps not by CCTS. That's if I press that this be an actual implementation in conformance with certain standards (like CCTS) and with the UBL model/BIEs. My fallback would be to just hide this from external visibility in the application away from the collaborations but that seems a bit cowardly of me so I'm trying hard not to use that approach unless I have to. All the best Stephen Green Quoting "G. Ken Holman" <gkholman@CraneSoftwrights.com>: > At 2007-02-09 06:11 -0700, stephen.green@systml.co.uk wrote: >> I just got to a fairly stable state with a customization of >> the UBL Catalogue for an opensource price list product. > > I'm very sensitive to this being called "a customization". The > committee has already defined "a customization" and an instance of a > customization must also be an instance of UBL: > > http://lists.oasis-open.org/archives/ubl/200606/msg00095.html > > An instance with no namespace or only one namespace is not an instance > of UBL, so I feel very strongly this cannot be called a customization. > I'm investing a lot of time into what I believe the committee calls > "customization" and this is really muddying the waters. > >> After >> making a schema as previously mentioned with zero namespaces >> (or at most one) > > Then it isn't UBL. > >> 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). > > I don't know what you are saying here ... there are a number of > namespaces in a UBL instance. > >> 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. > > That isn't UBL ... if the tools don't accommodate the definition of the > data, then please change the tools, not the definition of UBL. > >> 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. > > Can you please find another word for this? This is not "UBL > Customization", and we have tried to be careful and we are at an > important juncture as we start deploying customizations. > > If we use this word for what you are doing, then I'm very concerned > about how all of our efforts may become fragmented and confusing to our > new user community. > > . . . . . . . . . . . . . . . Ken > > -- > World-wide corporate, govt. & user group XML, XSL and UBL training > RSS feeds: publicly-available developer resources and training > G. Ken Holman mailto:gkholman@CraneSoftwrights.com > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) > Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/u/bc > Legal business disclaimers: http://www.CraneSoftwrights.com/legal > > > --------------------------------------------------------------------- > 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]