[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes from Joint Meeting 2 September
1. Welcome from Co-Chairs (Tim McGrath and Lisa Seaburg). Attended: Mike Grimley, Bill Meadows, Tim McGrath, Lisa Seaburg, Stephen Green, Ken Holman, Marion Royal, Monica Martin, Chin Chee-Kai, Tony Coates, Jon Bosak, Sue Probert, Anne Hendry. 2. List Containership - (I think I lost some of the content of the discussion, things were happening pretty fast.) This issue has made people put pen to paper and really think this out. This is one of the two questions outstanding that prevent us from having schemas without a resolution. The second issue being codelists. The decision has been made by the NDR group, and the concern of the LCSC members that are trying to implement this. We do need to close this issue by the end of the week, because of the time frame we are in. The paper that was sent out needs to be updated after the discussion from the list serve. It is interesting the conversation going on between Chee-Kai, Arofan and Stephen regarding documenting the smaller to larger samples and the processing of them. To describe the problems: The NDR rule 116, any elements with the cardinality of 1..n, must be contained in a list element. As we go through this there are a couple of things that come out of implementing the rule (regardless of whether or not it is implemented) the wording is ambiguous and needs to be re-worded. Rule 116 was formally extended. Tony helped put that together. with Case statements of how to do it. There is no dispute that if we are to have list containers, these rules would work. These rules were put together for the reason of readability and processing performance. There is a ease of usability with containers. Ken had an example within his email regarding the address. Keeping the processing generalized when using the containers. TM: I don't see either decision as being terminal. This is more a quality of design issue rather than work or don't work. Also it seems to be best practice to use list containers within the XML using industry. TM: The idea of having another level of complexity, and also increase in size by having more elements, and lastly the idea that list containers can be based upon a rule like cardinality. We end up with a logical model that doesn't have a 1 to 1 correlation to the schema itself. The list container position paper, sections 3, 4 and 5 describes the tax total and is a pretty good example. It is potentially a list within invoice and contains lists. We flagged what we felt should be list containers, in this example on page 11. We identified associations that we thought would occur more than once. In sections 4.2 and 4.3 they describe the TaxTotals List. Section 5 is the automated case. It implements the rule 116 completely. Lets talk about "Readability". This is now geared toward the tools you use to access the instances and how they use them. In text mode most of these are unreadable anyway. Discussion Points: - We need to either do the containers or not do them, but not do them only when we think it is necessary. Positions: Section 3: no use of containers Section 4: selective use Section 5: automated use. The symmetry and knowing whether you are working with a list or not. - The arguments going against the Section 4, is that it is no longer symmetric, it is not consistent. No one seems to be standing up in favor of this choice. - If we extend and it changes an element from non-list to list, then it would change the container element and this would really mess up the processing. - The examples that Stephen did were good. SG: I tried to keep it simple with merely looking at one list (InvoiceLine). I took the InvoiceLine making it 1,000, to try to examine if there was any performance issue. Then looked at having the list and then not having the list. I used instant Saxon, because it gives a processing time. I think I covered most normal things. There was no difference between the two. There was a margin of error within time of about 10%. There was different time every time I ran this. You have to run it 10 times to get a real figure. There was no difference in processing times. - There are only two directions worth exploring. One is the generic list element, semantic free element. This will work. Two is to go with Ken's idea, no you can't have semantic free containers on an element by element basis. Obvious candidates can be figured out ABIE. If an element is already comprised of like names elements then you don't need a middle level list. - KH: I am suggesting that we are required to add the list element over the contained elements. If we have containers everywhere then people are permitted to do it everywhere. Some Points of Discussion: TM: What I have learned is that the aggregations that we have been working on (the structures) that we have been building. Need to factor in, because of this problematic, processing issue. We can more elegantly more process the elements of document, if we ensure that siblings are always grouped together. If they in fact constitute a group. JB: Perhaps we can solve this problem with going back and saying maybe we want an ABIE here. TM: If someone wants to extend UBL, they may corrupt it. KH: Downstream processing has no awareness of the document model. - We are not going to solve the problem tonight. What we are bringing out is the point that we want to be able to ask for certain things in processing (like invoicelines). - Unless someone comes up with a better solution, then we are left with what they are suggesting. The question is: who can not live with that. - Logical groups and siblings are not necessarily the same thing. Is there a level of ABIE that we are missing. LCSC does not think so. - Are we at an impasse about this? - Does having containers cause more problems than it solves. - The status quo is the no containers, selected containers, or autogenerated containers. - Addressing the issue of processing 1.0 as it is: FPSC can do it like it is, it could be easier with containers, but there are ways around it. ***General agreement the rules as proposed cause just as many problems as they solve. - How about the vision of extensibility, does this have impact on what we do later on. - We are still alittle bit fuzzy about this. One of the first assumptions what that we needed containers because of the addition of elements through the extensions. This allow you to localize the additions. In the case of adding, this brings these together with like things. If you added address lines without containers, they would end up at the end of the document, and not be with the others and couldn't be put with the others. ***We agree we are not happy with the proposed rule, we would rather live without it, then to do the NDR rules as stated. Can NDR propose a better rule? - The Do Nothing Option, continue with the way we have been going. This is livable to the LCSC and the groups within that are implementing the rules into their schema. - There may not be a strong enough or robust enough a model to deal with the extensions and this is a issue that needs to be addressed. Issues for tomorrow: - We would like the NDR to reword the containership rules. - Explain why this issue is so important to people with a document processing background. - Do we get enough benefit by defining the non-semantic containers to put with the problems that arise from that. Those problems: 1) Extension by adding second instances, something that didn't have multiple occurrences and now does. 2) 3. Scheduling for 1.0 release (see LC schedule attached) Week 9:LCSC - draft of the index Week 9:NDRSC - (8/27) Editing of NDR Doc, checklist of available to LCSC. Week 8:NDRSC (9/3) Editing of NDR Doc, checklist of available to LCSC. Week 8:LCSC - model and xsd schema Week 7:NDRSC (9/10) Cleaned up version of rules with new numbers assigned to groups with some narrative before Mark leaves for TC154. Week 7:LCSC - Week 6:NDRSC (9/17) Full narrative draft of document to NDRSC. Week 6:LCSC - Week 5:NDRSC (9/24) Start review with NDR Doc. Week 5:LCSC - finalizing schema, draft of FAQ (Anne) Week 4:NDRSC (10/1) Start review with LCSC of NDR Doc. Week 4:LCSC - documentation, sample instances (FPSC) Week 3:NDRSC (10/8) NDR Doc review by SC Week 3:LCSC - finalize documentation, instances are being reviewed. (FPSC) Week 2:NDRSC (10/15) NDR Doc review by SC Week 2:LCSC - Review - (FPSC), (ASN) Week 1:NDRSC (10/22) NDR Doc review by SC Week 1:LCSC - Review - (FPSC), (ASN) Week 0:NDRSC (10/29) Release on Friday Week 0:LCSC - Release 4. Next meeting * Wednesday 3rd Sept (regular NDRSC call - to be done jointly) ++++++++++++++++++++++++++++++++++++++++++++++++++++ Lisa Seaburg AEON Consulting Website: http://www.aeon-llc.com Email: lseaburg@aeon-llc.com Alternative Email: xcblgeek@yahoo.com Phone: 662-562-7676 Cellphone: 662-501-7676 "If you obey all the rules, you miss all the fun." -Katharine Hepburn ++++++++++++++++++++++++++++++++++++++++++++++++++++ --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 9/1/2003
BEGIN:VCARD VERSION:2.1 N:Seaburg;Lisa FN:Lisa Seaburg (E-mail) ORG:Aeon LLC TEL;WORK;VOICE:(662) 562-7676 ADR;WORK:;;;Senatobia;MS;38668;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Senatobia, MS 38668=0D=0AUSA URL;WORK:http://www.aeon-llc.com EMAIL;PREF;INTERNET:lseaburg@aeon-llc.com REV:20030902T172841Z END:VCARD
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]