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

[Tim McGrath <tmcgrath@portcomm.com.au>]

thanks tony, for the sanity check. i was afraid it may look like that . 
i guess i was a consultant too long - justifying what the client wanted! 
 this was not the intention, but bear in mind we are (sort of) arguing 
the 'against' case because NDR have already given the judgement 'for'.

i also had two problems with the 'for' case:

1. the only useful example of repetition was Invoice. Line Item and the 
structure was so complex it would 2-3 pages to show the schema or a 
repeating fragment!  this does sound a bit weak (i accept your 'small 
example' comment) so i think we should draw attention to it in the 
document.  i suspect the reasons we could not come up with too many 
other useful examples of repitition is that, having normalized the data 
models, we have actually created the mythical "qualifying structures" 
that list containers are supposed to provide an alternative to.

and

2. in scouring the mail archive and NDR lists i cannot find:
 - explanations of why performance is better.  as you say this is mostly 
heresay, the only technical arguments (from Bill Burcham) have been 
against this. i have now had some useful material from Stephen about the 
progamming aspects of list containers which  will (at least) recognise 
we have tried to address these matters.
 - any (valid) examples of improvements in legibility.  thank you for 
the Internet Explorer example - i will use that.

I recognise that post-Montreal we attempted to develop 'selective list 
containers' in our models.  this has proven difficult as the decision 
should really be based on document instances, and this is too hard to 
predict.  (note the PhysicalAttribute example).  a point i could add 
when using selective list containers is that we also create a problem 
where implementators cannot immediately identify which structures have 
list containers and which don't, e.g. "does BasePrice have a list?" or 
worse still "does BasePrice have a list within Invoice?"

I feel we can stand by the conclusion, given that we do attempt to make 
more of the 'for' case.  

Finally, i note with interest your comment about 'annotations' and urge 
you to bring these to the attention of the NDR group( if you have not 
already).  They are currently debating which flavour of annotation 
(documentation or appinfo) we should use.  you are are suggested both 
are irrelevant ! or is that just for 'reference' (which i confess to not 
understanding)  It then begs the question of where else the meta-data 
(which contains the critical semantic definitions of the entities) can 
go in the schema.  We have stated the the schema is the only normative 
form of UBL and so I dont see how we can avoid this information being in 
there.  But seriously, are we going to be guided by TurboXML? i know 
that sounds fatuous but in the history of design we sometimes have to 
take a lead.  we could have the chicken and egg debate about demand 
versus supply forever. Think of the now trite limitations put onto 
designs because of perceived limitations of tools.  In Montreal we 
rejected the idea of limitations on tag name lengths simply because some 
RDBM's dont handle more the 32 caharcter column names!  There is a 
principle at stake here.

Regardless of that issue, the point of concern here is not our 
"difficulty of making annotations relevant to all usages when they are 
attached to a global definition" - it is that each usage needs its own 
global definition.  rather like your comment about AddressLine0-7List 
and AddressLine1-3List,  my point is that we need different list 
defintions for each usage (i.e. AllowanceChargeTaxCategoryList is not 
the same as ItemTaxCategoryList).  The annotations merely makes this 
difference clearer - it is not the annotation that is the problem 
(removing the hazard warning signs does not make the road safer).


Anthony B. Coates wrote:

>** 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.
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php.
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160