Re: [ubl-lcsc] Re: Position Paper on List Containers

["Anthony B. Coates" <abcoates@londonmarketsystems.com>]

** Reply to message from Tim McGrath <tmcgrath@portcomm.com.au> on Fri, 29 Aug
2003 17:14:25 +0800

At the risk of sounding cynical, my first impression was that this document
seemed to be nothing more than a document that reaches the conclusion that its
authors had decided beforehand.  In particular, the fact that the examples do
not show *any* repetitions strikes me as odd.  I can see how that helps that
case against lists, but really, if we never plan any repetitions, why would we
need lists anyway?

In section 3.2, you show an element reference containing a schema annotation. 
I've never seen such a thing before (so I guess I haven't studied the UBL
Schemas closely enough).  Certainly TurboXML avoids such constructs, even when
they exist, by moving such annotations to the matching element declaration. 
This is a Schema structure we need to avoid if we are to make the UBL Schemas
universally usable.  This is also important because one of the arguments
against containers seems to be related the difficulty of making annotations
relevant to all usages when they are attached to a global definition.  However,
since annotations attached to references are not robust, this is a potentially
spurious argument.  The XML Schema spec certainly does allow for annotations
within references, but without consistent tool support it's one of those
features that I would normally avoid.

In section 6, you mention readability.  If you read XML documents using Notepad
or vi, container elements do not help readability.  However, if you use a
folding XML editor/viewer, even Internet Explorer, containers are great for
folding up a repeated group of elements that you do not want to look at.  You
do not need hundreds, nor even thousands, of items for this to be true.

The question of what happens when an item is 0..3 in one place, and 0..7 in
another, is a valid issue.  If it were up to me, I would simply generate a
separate list type for each, since I don't see this kind of thing occurring
often enough for this to be a huge problem.

Your description of what happens with "BasePrice" for 0..1, 1..1, and 0..n is
completely correct, but strikes me as a complete non-issue.  Is your position
that you don't want containers, but if you do have them, you insist on them
being used absolutely everywhere?  That's too much like Australians having to
vote for the republican model that everyone knows they don't want - a great way
to make the old system look good.  With the most recent proposal, we
specifically tried to avoid containers *unless* something could occur more than
once in a particular context.  I would have thought that you would have seen
that as an improvement.

It's important to reiterate what has been made abundantly clear in recent
meetings - containers are not useful for small documents.  If we confine
ourselves to small documents, and decide that scalability is not an issue, then
getting rid of containers will be fine.  There's always EDI for the big
documents, after all.  Small examples are always going to make containers look
bad, and of course people tend to put the smallest possible examples in
discussion documents.  One needs to be aware of how that can skew the view of
reality.

As for the conclusion, "From this exercise we have been unable to demonstrate
any clear architectural benefits in using List Containers, either in processing
performance or readability", the document didn't address performance in any
noticeable way, so of course you didn't demonstrate any performance benefits. 
That isn't a conclusion, and it seems a bit too misleading for those people who
only read the introductions and conclusions of documents.

All that said, I still feel that the case *for* containers has not been clearly
enough made.  While I have been told that it helps with the processing of large
documents, I myself couldn't give a concrete example of when that is true, and
why.  I'm wondering if we need those examples, from the people who have them,
if we are ever to reach closure on this issue.

	Cheers,
		Tony.
====
Anthony B. Coates
London Market Systems Limited
33 Throgmorton Street, London, EC2N 2BR 
http://www.londonmarketsystems.com/
mailto:abcoates@londonmarketsystems.com
Mobile/Cell: +44 (79) 0543 9026
[MDDL Editor (Market Data Definition Language), http://www.mddl.org/]
[FpML Arch WG Member (Financial Products Markup Language), http://www.fpml.org/]
-----------------------------------------------------------------------
This Email may contain confidential information and/or copyright material and is intended for the use of the addressee only.
Any unauthorised use may be unlawful. If you receive this Email by mistake please advise the sender immediately by using the reply  facility in your e-mail software.
Email is not a secure method of communication and London Market Systems Limited cannot accept responsibility for the accuracy or completeness of this message or any attachment(s). Please examine this email for virus infection, for which London Market Systems Limited accepts no responsibility. If verification of this email is sought then please request a hard copy. Unless otherwise stated any views or opinions presented are solely those of the author and do not represent those of London Market Systems Limited.