[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]