[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-ndrsc] Containers (long)
Jon: I am afraid I may not be able to join the next call in which these issues are discussed, but I wanted to express my views on this important issue at this point. I support your proposal (despite feeling that the lack of containerization will prove to be a barrier to adoption of our schemas). It is not worth further discussion, and, as you state, we can always fix it in revision should implementation prove to us the need for more containers. I guess my concern is this: we have a clear view (especially in LCSC) of a model and methodology that is focused on semantic completeness, and - as a direct bi-product of our focus on that model - we prefer a one-to-one correspondence between the model's semantic constructs and the syntactic constructs in the XML. Hence, no containers. I guess I believe that this is putting the cart in front of the donkey. I always believed that UBL's first order of business - their primary deliverable, if you will - was a set of schemas that were easy to use, easy to extend, and got the job done. The modeling methodology was a secondary deliverable, existing in support of XML schemas themselves, helping us produce complete and understandable schemas. We already have a "syntax-neutral" methodology from ebXML Core Components, and UBL's focus was supposed to be different - on the XML itself. I'm not sure we have maintained this focus sufficiently. I fully appreciate that we have helped clarify the virtues and failings of the ebXML CC methodology in producing the UBL library. However, I feel that our modeling methodology is too complex for general use - it took us quite a while to understand it internally, and - powerful (and even fascinating) as it is - I believe that the majority of our users will not bother with it. They will simply take our schemas and use them. Containerization may or may not produce efficiency gains in processing: this remains to my mind an open issue until someone does some very comprehensive tests, which we have not, and will not do within the necessary timeframe. Questions about ease-of-use and comprehensibility remain, however. I believe that containers contribute materially to these things in a world where most developers won't be working from our semantic model, but from the XML schemas. (This is also a major point in the local-versus-global debate. Local is, pure and simply, harder to master. There's a good quote on this point from Eric van der Vlist in his "XML Schema" book from O'Reilly, page 20, last paragraph, first edition.) A few examples, taken from our discussions: (1) Containers are not absolutely necessary for writing presentational code, but they make it easier, especially for the unsophisticated. (2) Similarly, containers provide a degree of encapsulation that makes code reuse easier, and makes the XML easier to understand. Not absolutely necessary, but nice to have. (3) Tools *can* present XML documents without having containers to give "collapsible" file/folder views, but it's awfully nice to be able to collapse the bits you aren't focused on at the moment. We need containers for this. (It helps to remember that most developers aren't concerned only with semantics, but also with the syntactic constructs with which the code directly deals. They care about the semantics, but they also care about how the syntax constructs are packaged.) These are the kinds of minor optimizations to our XML formats that we have traded for a greater degree of consistency with our semantic model. I think this is a poor trade-off. It makes life easier for us (in creating and maintaining our library), but not for our users. Again, I agree that we should go with the status quo for now: we can fix this in revisions if it proves to be a major problem, as has happened for some other e-business vocabularies. And I'm not completely satisfied with the proposed containership rules, either (although I do feel that in this case the cure is in fact better than the disease.) In the interests of completing a 1.0 version in a timely fashion, however, I support withdrawing the existing containership rules. Cheers, Arofan -----Original Message----- From: jon.bosak@sun.com [mailto:jon.bosak@sun.com] Sent: Monday, September 08, 2003 9:08 PM To: ubl-ndrsc@lists.oasis-open.org Subject: [ubl-ndrsc] Containers NDR SC members, I am not a voting member of the NDR SC, but as a concerned observer, I'd like to urge that you consider withdrawing the current rule regarding list containers at your meeting on Wednesday. Let me be clear that I share the feeling that we need more containerization rather than less. In fact, as I indicated during the joint LC/NDR calls last week, the current example showing multiple line items rattling around loose inside the invoice document makes me very nervous. I believe on general principles (*very* general principles) that this is going to cause problems for processing applications farther down the line, and the excellent position paper developed by LC on this subject has not convinced me otherwise. That paper has, however, convinced me (1) that the proposed cures are worse than the disease and (2) that we don't understand the potential problems well enough to propose a better solution at this time. Furthermore, it appears that there are no currently demonstrable performance consequences large enough to offset the additional complication that would result from the generation of list containers. With regard to the proposal (which I believe was mine) to assign LC the task of manually indicating list containers in the data model, the reply that LC has already identified the semantically meaningful containers seems to me a valid one. LC is saying, in effect, that they have already containerized everything that made sense to put into a container, and that if I'm bothered by the sight of line items running around naked, then the onus is upon me to provide a good semantic reason for categorizing the group as an ABIE. And I don't have one. I've listened pretty hard to the recent discussions on this point, and my conclusion is that we will have to revisit this question in some future major (non-backward-compatible) revision, but that we don't undertand the problem well enough right now to design a clearly appropriate solution. No one has questioned that the schemas will work if they remain as they are now without the application of the list container rule. Since it appears obvious that the application of an automatic container generation rule will significantly complicate the schemas, and since we cannot show a clear benefit commensurate with this additional complexity, I think (as an interested observer who cares about our time line) that we should proceed without nonsemantic containerization until experience can show us a better way. Jon 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-ndrsc/members/leave_wor kgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]