Dear all
please find attached a copy of today's minutes. If there are any corrections
to these please provide them to me within 5 days, otherwise if no objections
are raised these will be automatically approved then.
Regards
Mavis
Co-chair
----------------------------------------------------------------------------
----------------------
UBL NDR SC Minutes July 2 2003
Present:
Danny Vint
Mavis Cournane
jack gager
Sue Probert
Anthony Coates
Stephen Green
Arofan Gregory
Lisa Seaburg
Mark Crawford
J Glace
Paul Thorpe
Gunther Stuhec
bill burcham
Jon Bosak
anne hendry
Michael Grimley
quorum achieved.
Discussion items:
1. Containership
2. Namespaces
3. AOB
1. Containership
AH - In LCSC yesterday it was agreed Arofan, Stephen and Tony would take
this offline and resolve the question. Tim drew up a terms of agreement to
decide the scope.
MC - Containers are an instance not a schema issue.
TC - no the containers have to be in the instance as well.
MC - In the schemas we only have to define a container element.
TC - The container generation should be done automatically.
MC - What the containers are is more an instance issue than a design issue.
BB - The decision to use containers, which ones to use for a particular
document is an instance issue.
TC - I would call it a structure issue.
MC - Is this really something for NDR or for LC?
JB - Identify up front the lists for which containers are appropriate and
you put those in the spreadsheet.
I am puzzled by Chee-Kai's point if you need individually named containers
or whether you have something more generic. If you are going to generate
these things I don't see how you have any other option than an anonymous
types.
Oh, yes you came up with an algorithm for naming these things.
DV - The thing with single name falls apart when you want to control what
the content model is.
That is where Chee Kai's model falls apart.
JB - does anyone have a clear idea what container you would want identified
that you could not see coming at design time. You should be able to look at
the data model and say here we need a container.
TC - what would be the ad hoc basis you would chose to have a container in
one spot and not in others. Developers look for regularity. Why have
container in one area and not another.
DV - I could fall on either side of this discussion.
JB - What is ad hoc?
SP - It is a business decision - it is not ad hoc. It is whether something
that can be a rule or not given a particular document.
SG - The one to many rule is a compromise. Really, you want it to be
something that human being says these elements are grouped together.
Chee Kai balks at this. You are creating an artificial rule based on the
current content. If somebody messed with the cardinality someone would say
this rule doesn't apply anymore.
JB - you are saying the application of a mechanical rule happens to work for
these particular cases but could go wildly wrong for the general case.
BB - Nine months ago we decided it was not advisable to have a rule for
container elements. We said that an Aggregate BIE is what the modelers would
be used. There is precedence in DB design for at an analysis level for
expressing associations with cardinality. At the LC level they would be
expressing their constructs, the translation between that an XML we would
either make the decision to have one to many expressed in lean XML or XML
with extra container tags. It should be led by an example of how lean XML
would break down.
SG - Chee Kai did knock this down. I believe him. In my own development I
have never used a container. I use schemas that do and don't have containers
and I don't have any problems with schemas that don't have containers.
JG - I think containers make things more logical. In some practical
implementations there are complaints about overhead for processing.
MC - Given that a subgroup has been asked to look at this are we
comfortable at letting them work at this and come back to us on this.
My thought on a general would be allow for containers and leave it up to the
implementors.
Is this really an NDR issue?
BB - Some NDR people want to create a production rule to spit out container
elements.
JB - Shouldn't that be something for LC to go through this and decide what
needs a container.
AH - Let's look at Tim's email to see a clear description of what they are
asking for.
BB - We will solve 80% of problems if we get rid of the generation of
containers.
JB - The alternative is to create a list marker in the spreadsheet that is
not an ABIE.
BB - If it is not an ABIE I will have to expand the context stuff to deal
with it. If it is an ABIE I can say the content of this thing is a recurring
property BIE and later I can add 3 other attributes under where that
pertains to everything in that list.
SP - You will never have the concept of context for a container.
TC - Where the container provides metadata that applies to all, that is
something that cannot be auto-generated.
The automatic generation only works in a global rule where you would not
want to have any extra meta-data/
JB - The question seems to be - is there a way to auto-generate wrappers
for repeating elements that is guaranteed to give you results that you won't
barf over. If there is no guarantee when we through a wrapper we are saying
these things are alike, and shouldn't it be up to the business people.
AG - There was a long discussion on whether they were semantic things or
not. We can do containers cleanly without making people barf too often. We
are better having some containers we don't want than not having containers
auto-generated.
If the people creating the business models were optimizing the schema you
would have no problems. That would be an implementation model which we have
avoided up to now. The issue is getting a little clouded.
JB - I am hearing that there is a layer of human judgement that does not
belong to LC.
AG - Maybe the LC people should be deciding which ones should have
containers.
JB - We are saying there is a design decision layer that is not a business
one but is a sanitary layer. How about taking the current spreadsheet, a
rule is applied that in 98% of cases produces the containers we would have
generated on a case by case basis. Then we have a review process to look at
the outcome.
AG - My feeling, while that would be the best approach, I am not sure it is
worth the effort.
Stephen found only one case of something he was really unhappy with.
JB: Arofan you and a group of people need to go off and do that level of
specification.
MC: As chair does anyone object to this approach of looking at our rules,
specifying and coming back next week with something.
Let's assume as there are no objections that NDR concurs.
2. Namespaces
MC: We had a disagreement on how many namespaces we were going to create.
LS: The last rule was a namespace per functional area not per document. I am
happy to say we might have missed something. The rules were supposed to
reflect the modnamver.
AG: The rationale for functional areas, was the reuse of common thing. If
what we are doing with our rules generation is to create two different sets
of things, then the functional area nolonger makes sense.
BB: On the functional area, my recollection we would define one namespace
for each functional area, aggregate types etc.
MC: I am getting a sense we are starting to question things that are not
broken.
LCSC are not in conformance with the rule, an LCSC person is espousing
difficulty with the rule. Is our decision broken.
AG: I think it is a forward looking one.
TC: In looking at the instance documents some of the structures considered
necessary are surprising. In LC they wanted to know whether we wanted to
stand by our rules.
MC: OUr message should be that we are standing by this.
AG: They have not defined functional areas the way we had intended.
MC: Maybe we should ask LC to give us back what these functional groupings
should be so we can incorporate them.
AG: We need to explain to them at what point is an aggregate common.
BB: We are saying to LC is that there is a notion of package that you guys
need to decide on. We should ask them to identify what package there thing
is in.
AG: We need to give them a hard rule. If something is not used in two
functional areas it is not common.
MC: These modules we are creating, which is some level of aggregation within
the schema within a given functional areas, because these things are context
dependent in fact BIEs are not going to be reused across multiple areas
because they would be different BIEs.
AG: You are talking about packaging a schema implementation of a business
model.
BB: I think we aren't adding a rule, more a clarification.
They don't have to use the term namespace, they can have the concept of a
package.
AG: The activity you are suggesting aligns with business process within the
notion of context.
MC: Bill will you talk to Chee Kai with this.
AG: The modelers should assign constructs to packages. These are related
groups of document types that facilitate a business process. These are
Common Aggregates, and functional areas. There are only 2 functional areas
in V1. Anything used in more than one functional area is part of the Common
Aggregates.
SG: Is there a proposal here to recreate the reusable spreadsheet.
SP: I hope not.
BB: The proposal is to go in to the reusable spreadsheet and add a column to
specify to which package does the component belong.
3. AOB
3. Regrets for next week
Mark Crawford
Arofan Gregory
Mavis Cournane
Sue Probert