Re: [ubl-dev] Aggregate components: XML complexType and type= vs. ref=

[Stephen Green <stephengreenubl@gmail.com>]

Hi Michael

Not often we get questions like this on UBL-Dev. I guess
we might do so more in future.

Firstly you've asked about CEFACT schema design. I'm not
an expert on that but from what I've seen of the resulting
schemas I'd say it was a fairly robust design so I'd have
a look again at the XML and see if in fact there is as much
of a problem as you think. Even in UBL which uses a very
different schema design (which predates the CEFACT one
- which may answer your second question) there are two
namespaces in a document which appear in the XML.
Having two namespaces, one for aggregates and one for
basics (ABIEs and BBIEs) shouldn't be a huge problem
with either schema design. The reason there are two schema
designs, one for UBL and the other for CEFACT is historical.

{What follows is not for the squeamish and comes only from
my own version of events so please don't read if you are you
might be upset or are like me inclined to get too drawn into
arguments and later regret it...}

UBL TC back when I first joined it (I think that's 2003) had a
big debate going on about whether to use global or local
elements. Global types in a schema is common but global
elements were not so common at that time and really became
more common, I think, as people have used substitution in
schemas which requires it. I only witnessed the debate from
a distance but it got pretty hot and from what I saw it seemed
that those in favour of local elements failed to get their way in
UBL and took their preferred design off to CEFACT where it
became part of the general CEFACT schema design. I'll
get flamed, I expect, for putting it like that but it's how I saw
it at the time before I got heavily involved in UBL TC. I'm not
saying which 'side' was right and which was 'wrong' if there
can be a right and wrong at all. I don't think there can but I'm
saying this just to make it clear that UBL had already made
a clear decision about this infamous 'global versus local' issue
and pretty much the opposite decision was made in CEFACT
and I'd say the decision in CEFACT seemed to have been
made later and I couldn't say for sure that it was connected to
the UBL decision but it did seem to be to myself as a relative
outsider. Amazing how hot a debate can get about what seems
so trivial but I got the impression it was over tool-related issues
about being able to create artefacts automatically from the
schemas which wasn't all that easy at the time if the elements
were local. I say this because I had similar ideas about how to
use the schemas in this way and I thought I recognised the
arguments in favour of local element definitions from my own
experiments but appreciated that it all revolved around how tools
behaved at the time I thought, whereas the arguments which won
most support in UBL TC were that the decision should not be
based on tools but on the ideology of the design itself. Anyway,
I lot of people might not like me risking opening up that debate
again as it took up so much time and energy back then. The
decision seems to have been stuck to even until now in UBL TC.

http://www.documentengineeringservices.com/presentations/UBLandUNCEFACT.pdf
see page 5

So it seems this difference of approach is well set into the two
standards and may never be resolved. However, it should not make
a huge difference and should not be all that noticeable in the XML
messages/documents themselves so I'm surprised at how you've
experienced a difference and wonder whether the difference might
be more to do with how you've been writing the XML instances, not
so much what is dictated by the schema design.  know it's all very
complex though. I did do some experiments some time ago (and
maybe the CEFACT design has changed since then) in which I
found the same instance could have *both* a UBL design schema for
it and a CEFACT design schema. I also found CEFACT schemas
could be generated from UBL schemas (but not vice versa) or was it
the other way round, I don't remember. All this seemed to make the
issues seem so academic that they hardly mattered and this is
probably the case since there has not developed any one hard and
fast way to design a schema even after all these years and you don't
tend to hear people comment too much about schema design when
they talk about any given XML standard. Most hardly even know what
schema design was used, e.g. could you tell me which one SAML
uses? or WSDL? In fact W3C hardly seem to bother with schema
design or even schema at all when they develop key standards like
XSLT. So who cares? There are many schema designs like all global
types / local elements; all local types / local elements; all global types
/ all global elements and various hybrids (like CEFACT's which seems
to be local elements with exceptions). All have their strengths and their
weaknesses. The strengths with UBL include that you can substitute any
element. I'm not sure people do though. At one time we thought that
would be a key part of how UBL would be used but there are problems
with that which means it might not be so crucial. It might seem an easy
thing to change but it is part of UBL now and still has enough benefits
as it is that a change would be for the worse. That's my view and I had
no preference either way for local/global choices. My only part was to
throw a spanner in the works once by persuading UBL TC to make the
schema *all* global elements rather than mostly global, due to problems
with derivation which now seem academic. It was enough to warrant a
completely new version though so we had UBL 2.0. That's my dubious
claim to fame. Now it is at least easier to describe the UBL design but
it is still largely academic unless you are trying to do certain things like
customise in certain ways and these are no mainly out of favour in the
UBL customisation guidelines which favours use of the extension element
'any' in the top of the UBL document over complex derivation of elements.
Not really of any impact on normal use of UBL messages and I'd be
surprised if the CEFACT design had any obvious impact on users of
CEFACT messages either.

No I'll run away and stop reading my emails for a few days in case I get
flamed :-)

Best regards

Stephen D Green


2009/10/20 Michael Strasser <Michael.Strasser@brisbane.qld.gov.au>:
> I am learning about (and hopefully contributing to) the Australian
> standard called eDAIS: electronic Development Assessment
> Interoperability Specification.
>
> eDAIS is defined in UML using a methodology derived from UN/CEFACT
> Modelling Methodology (UMM).
>
> The XML schemas exported from the model define all aggregate components
> using constructs like:
>
>  <xs:element name="Application" type="da:Application"/>
>
> which surprises me because of the ‘wrong namespace’ documents that
> result:
>
>  <pcat:ProposeCreateApplicationTransaction>
>    <!-- Application element is defined in da namespace. -->
>    <pcat:Application>
>      <da:ApplicationNumber>123456</da:ApplicationNumber>
>      <!-- etc. -->
>    </pcat:Application>
>  </pcat:ProposeCreateApplicationTransaction>
>
> The creators of eDAIS inform me that they are following the UN/CEFACT
> XML Naming and Design Rules 2.0. On my first reading of that document it
> appears to specify this schema design but isn’t very clear.
>
> But I notice that UBL, which has similar provenance, uses references
> like this:
>
>  <xs:element ref="cac:OrderLine" maxOccurs="unbounded"/>
>
> I think the use of references is better because it creates XML
> documents that are more easily processed: all components are in their
> ‘correct’ namespaces.
>
> Can someone please explain the decision-making process for UBL and how
> it was decided to apparently contradict the UN/CEFACT rules? Or are the
> ‘rules’ not so clear-cut? I have read the UBL 2.0 NDR and I am even
> more confused (i.e. doesn’t [RED2] contradict [ELD3]?)!
>
>
> Thanks in advance
>
> Michael Strasser
> Brisbane, Australia
>
> **********************************************************************
>   This message has passed through an insecure network.
>    Please direct all enquiries to the message author.
> **********************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>