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