[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-lcsc] Re: Position Paper on List Containers
** Reply to message from Tim McGrath <email@example.com> 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:firstname.lastname@example.org 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.