Re: [ubl-dev] CCTS_CCT Defined CCT but not used

[Stephen Green <stephengreenubl@gmail.com>]

Good question.

I'm probably not the ideal person to answer this but I reckon
it goes something like this:

If you are customising UBL or if you are writing another
language which you want to interoperate with UBL you will
want to have good alignment of datatypes. If you are trying
to align using a language based on EDI rather than XML
then the UN/CEFACT CCT spec aims to give you a lot of
commonality with other languages written to comply with
it. This includes use of a common set of core component
types (the CCTs) which are defined in the UN/CEFACT
CCT Specification (CCTS). If on the other hand you are using
XML then you might get even better alignment of datatypes
by using a common XML representation of those CCTs. One
way to define that representation of the CCTs is with W3C
XML Schema. This is the method chosen for not just UBL
but several other key standards based on CCTS / XML. A
key set of these all chose early on to use the same Schema
for their CCTs in order to maximise interoperability (to avoid
pitfalls due to differences in how their CCTs were represented
like whether a supplementary piece of metadata was an
element or an attribute). If you want to do the same with a
custom document or even a custom (or alternative standard)
language then you can use the same CCT schema as a
basis for your datatypes to ensure you are starting with best
possibilities for alignment of your datatypes with the other
CCTS-based languages. This is one possibility; another is
to just implement the CCTs in any way you choose and just
seek to conform to the CCTS - OK if you are implementing
something very different to UBL, etc (say written in JSON or
RDF or EDI, for the sake of argument) but perhaps not ideal
if you are doing something closer to UBL (or OAGIS or GS1
-XML...) and want to make life easier for mapping and
translating between these languages. Plus there is the factor
that you might want to think about future alignment with
UN/CEFACT standards like the cross-industry trading docs.

Sorry, this is longwinded. I haven't even got to the main
point yet: Which is that 'using' the CCT datatypes (basing
your unqualified or qualified datatypes, as CCTS calls them,
on those CCTs) does not require any link between the
W3C XML Schema definition of you datatypes and the
corresponding W3C XML Schema definition of the base
CCTs. It just means you need to look at the CCT when you
write your datatype so you make your datatype a logical
specialisation of that CCT (see CCT Spec if you want to
know more, I'm a bit behind on how it goes these days).
So it is kind of there in the schema set for reference, mainly
because the W3C XML Schema specs don't seem to cater
for this kind of derivation at a conceptual level - only at an
implementation level (although we never really decided if
the use of the schema derivation mechanism in XML Schema
was appropriate for showing derivation of a 'datatype' on a
'core type' - those terms being the CCTS-semantics ones).

So in short, unless you are extending UBL or writing a
language to align with UBL or its CCTS neighbours, you can
safely ignore that CCT schema (even remove it if you like).
Just treat it as technical reference material. But maybe think
of it as like an 'interface' in the object oriented sense (though
I get the impression it isn't meant to be strictly conformant
to OO principles).

Apologies for long treatise. Again, this is not necessarily
the account of this everyone else designing UBL would have
agreed with, just my own take on what was done. Maybe the
others involved in including the CCT schema in the set are
no longer even on this list so I thought I'd better pipe in.

Best regards

Steve

Stephen D Green





2009/6/18  <jaymuz@optusnet.com.au>:
> In CCTS_CCT_SchemaModule-2.0.xsd the namespace:
>
> xmlns:cct="urn:un:unece:uncefact:data:specification:CoreComponentTypeSchemaModule:2"
>
> is defined however no elements or attributes with the cct prefix appear in the schema document.
>
> Why is that?
>
> John
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>