RE: [ubl-dev] XML NDRs: UBL 2.0, 2.1, CEFACT 2.1, 3.0

["Roberto Cisternino" <roberto@javest.com>]

I went into code lists because there are data types using enumerations.

Here I see lot of "imports" which is not very light:

http://www.unece.org/uncefact/data/standard/QualifiedDataType_8p0.xsd

I think this practice is mentioned in CCTS or NDRs.

> Roberto,
>
> Not sure why you went into code lists as I didn't address it in my reply
> at all.  Rather I just focused on the difference between CCTS and NDR and
> did not address any differences between UBL and UN/CEFACT.  You may want
> to do that analysis yourself, especially for v3 which creates specific
> packages for specific deliverables which is a paradigm shift in how
> standards are developed and delivered in that it breaks the monolithic
> approach.

I noted "packages", I am trying to understand which is the effort required
by implementers to keep their software updated with latest code lists.

But packaging is not removing enumerations from what I understand.
I would prefere to have a more stable document model with no enumerations
inside.

Thanks for the packaging info.

>
> Kind Regards,
> Mark
>
> -----Original Message-----
> From: Roberto Cisternino [mailto:roberto@javest.com]
> Sent: Monday, April 18, 2011 4:22 PM
> To: Crawford, Mark
> Cc: ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] XML NDRs: UBL 2.0, 2.1, CEFACT 2.1, 3.0
>
> Hello Mark,
>
> I am not an expert of CCTS 3 but I noted CEFACT schemas are too much
> binded with enumerations for code lists.
>
> Code lists are required to be updated separately from the business
> document.   Real business needs cannot wait UN/ECE or CEFACT deliverables,
> so for instance using UN/Locode most companies are required to add
> additional codes for new Port entries that are not available in the
> official code list.
>
> We have already seen similar issues with currencies the past year (see
> Turkey) and I am happy that UBL TC has choosen to decouple code lists from
> business documents.
>
> Anyway I am not surprised at all as UBL has provided always good examples
> for ensuring interoperability.
>
> UBL is standardized within an open process under OASIS OPEN, and this
> reason UBL collects requirements from a wide community and committed
> people for doing business not only standards.
>
> It is a fortune that UBL is working together CEFACT.
>
> Take care
>
> Roberto
>
>
>>>I don't know of any other
>>>business vocabulary published where the CCTS 2.01 CCT fragment is,
>>>expressly, the foundation of the schema tree ... and I would
>>>appreciate it if someone knew of others so that I could analyze their
>>>use of the schemas.
>>
>> Not used by UN/CEFACT since the CCTs were only intended as reference
>> material for creating unqualified data types which are the foundation of
>> the UN/CEFACT schema tree
>>
>>
>>>It is my second-hand understanding that CCTS 3 is not backward
>>>compatible with CCTS 2.01, and thus the UBL 2.x maintenance stream is
>>>obliged to stick with CCTS 2.01.  Which is fine, since it is meeting
>>>stakeholder requirements.  So all future UBL NDR 2.x will be
>>>documenting a schema tree based on CCTS 2.01 CCT.
>>
>> Disagree.  Would be interested to know exactly which aspects of CCTS3
>> you
>> consider not backward compatible as the artefacts are the same, only
>> more
>> robust which fits within the definition of UBL for backward
>> compatibility.
>> Would also be interested in exactly what aspects of the data type schema
>> UN/CEFACT uses for its 2.01 schema generation would break UBL 2
>> versions.
>> Further, would like to know which specific DTs from DTC3 and the
>> corresponding schema would break backward compatibility with UBL2.
>>
>>>I don't know what is in CCTS 3, but it was my understanding that it
>>>wasn't completed yet.  Rather than try and embrace a moving target,
>>>I'm waiting for CCTS 3 to be finalized, packaged up, signed off and
>>>delivered before determining how it can be used.
>>
>> CCTS3 and CDT 3 were published in September 2009.  NDR3 was published in
>> December 2009.
>>
>> Kind Regards,
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>>
>>
>
>
> --
> * JAVEST by Roberto Cisternino
> *
> * Document Engineering Services Ltd. - Alliance Member
> * UBL Italian Localization SubCommittee (ITLSC), co-Chair
> * UBL Online Community editorial board member (ubl.xml.org)
> * Italian UBL Advisor
>
>   Roberto Cisternino
>
>   mobile: +39 328 2148123
>   skype:  roberto.cisternino.ubl-itlsc
>
> [UBL Technical Committee]
>     http://www.oasis-open.org/committees/ubl
>
> [UBL Online Community]
>     http://ubl.xml.org
>
> [UBL International Conferences]
>     http://www.ublconference.org
>
> [UBL Italian Localization Subcommittee]
>     http://www.oasis-open.org/committees/ubl-itlsc
>
> [Iniziativa divulgativa UBL Italia]
>     http://www.ubl-italia.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>


-- 
* JAVEST by Roberto Cisternino
*
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor

  Roberto Cisternino

  mobile: +39 328 2148123
  skype:  roberto.cisternino.ubl-itlsc

[UBL Technical Committee]
    http://www.oasis-open.org/committees/ubl

[UBL Online Community]
    http://ubl.xml.org

[UBL International Conferences]
    http://www.ublconference.org

[UBL Italian Localization Subcommittee]
    http://www.oasis-open.org/committees/ubl-itlsc

[Iniziativa divulgativa UBL Italia]
    http://www.ubl-italia.org