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

[Stephen Green <stephengreenubl@gmail.com>]

"... 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. ..."

Sorry, I meant that the other way round
"which wasn't all that easy at the time if the elements were global."

Of course, generating a form in a browser which can transform
with XSLT actually in the browser (e.g. IE) is doable when the
schema has local element declarations (using 'name', not using
'ref' like you say Michael). This sort of thing is not really feasible,
AFAIK, when the elements are global since the XSLT would be
very complex as it would have to go looking, perhaps in another
document, for the structure to apply to the element and in the
days when these NDRs (naming and design rules) were being
designed there was no XSLT version 2 and so XSLT was limited
pretty much to handling a single document. It would be interesting
to know if this was the main reason for CEFACT NDR design
having so much use of 'local' elements. I think the main reason
why the UBL TC majority went for global element declarations
(originally in version 1 with some exceptions - IDs and codes, then
later all global) was to enable substitution groups in custom and
minor version schemas to allow an XML version of polymorphism
(through the W3C XML Schema 1.0 derivation methodology). I'm
not sure this has really worked out as well as hoped but the 'global'
design of the UBL TC's NDR (which like I say really predates the
CEFACT one and influences it via a kind of 'lessons learned') stuck
in the case of UBL and was kind of reversed in the case of CEFACT's.
So advocates of both designs got their way one way or another and
the world ends up with a choice of two designs. Like I say, it would
be neat to see if that has indeed after all this time allowed the two
kinds of benefits - autogenerating dynamic associated artefacts on
the one hand with CEFACT schemas (or subsets of them as they
are kind of big) [and I'd advise a patent search on that] - and on the
other the ability to derive custom elements through use of substitution
groups from UBL schema files. I still think it might be possible to
create CEFACT schemas from the UBL ones and get some of the
benefits of both designs for the same data model (the UBL one)
though not the other way round I think, regretfully - but that is for folk
to try out and prove or disprove themselves as it's so long since I tried
it there may now be too much difference in NDRs and I can't remember
(or find on UBL mail archives) the exact outcome of this impromptu
research effort. Something to try yourself if you have the inclination? I
do think, though, that either design has little impact on normal, out-of-
the box message validity - in UBL's case especially since I haven't had
time to keep up with the case of the CEFACT messages.


Best regards
---
Stephen D Green




2009/10/20 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
>>
>>
>