OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes UBL NDR SC October 15 2003


Dear all
please find attached a copy of today's NDR Minutes.

Regards
Mavis
----------------------
Agenda
1. Roll call and welcome from the chair (Mavis)

Mark Crawford
Mavis Cournane
Eduardo Gutentag
Jon Bosak
Paul Thorpe
Bill Burcham
Stephen Green
Jessica Glace
Gunther Stuhec
Tony Coates
Lisa Seaburg

2. Discussion of LCSCs position on not getting any new rules from us.

We will not go backwards on any version of the NDR document.
We will mark which rules apply for the beta release and which apply to the
final release
and this should do.

3. Go through the DraftAnalysis8.xls spreadsheet of LCSC comments/issues
Issues 14-16 provided by Lisa.


In last weeks calls there were a couple of points like this, we need to go
back and make sure we are marking things are new and allowing for their
non-compliance.  These new rules need to be discussed at the Face to Face in
joint meeting.

Lisa will take the current version of the spreadsheet and compare it with
the new one. Identify what has changed and differentiate bt rules
created to satisfy LC and those that are an added burden on LC.
We will address these at the F2F for the final release.

Another point is the code list work that Gunther just recently brought
forward.  This work is totally messing them up.  He is on the call pushing
them to follow this work, the code list work group had made quite a bit of
work (without Gunther because he was unavailable) now he is coming forward
pushing this work.  It may be that his stuff is what we want, but it is
making the job of getting the Beta release out very difficult, plus he is
stepping on the toes of the code list work group.  So, help me out here.
The NDR group needs to look at this work, make decisions and decide whether
or not it is a show stopper and should it be pushed as a "Critical" Issue.

EG: I have a question about this. That work has not been sanctioned by NDR.
How come Gunther is pushing it strongly.
2 Rules were approved as NDR 29j and 29k.
EG: It looks like he was conforming with what NDR asked him to do.
SG: It was not properly discussed on the LC call.
Deferred.

Issue 14 - Mark will write a rule for it.
AttributeFormDefault=unqualified is this correct?
GS: We are declaring attributes for supplementary components only.
Additionally, we said we could put global attributes for Identifier but we
have not formally
decided this or created any rules for this.
MC: Should these be qualified. Or is the proper way to have all attributes
unqualified.
NOt having them qualified, doesn't this assume they are declared locally
instead of globally.
GS: We have not decided any attributed for this globally declared attribute
group.
These attributes appear in Core Component Type schemas and in the
Representation term schemas. All the attributes will be declared locally in
each Complex Type
of the RT.
MC: All attributes will be declared locally in the CCT and the RT module.
However, in the RT module we have restrictions as we don't need all the
supplementary components.
JG: I think it is good to make it obvious where smth is coming from.
GS: It is clear that all supplementary components will be declared as
attributes and all CCT will have supplementary components.
For example, you have the CCT Amount and you have 1 supplementary component
that will give you additional info about the currency e.g CurrencyCode.

Issue 15 - MC I don't agree with this as it violates an agreed, established
rule that has been put in place.
The word "LOCAL" is not appropriate.
MC: I have problems if they have written smth with local element
declarations.
SG: He meant local to the code list but not to the schema.
GS: If we define for each codelist a schema, why define local elements for
this?
SG: He does not mean local in the schema.
SG: Are the rules strict enought to say you can't reuse a name?
GS: If you use a global name then it is not possible to reuse this name.
SG: It is globally declared but is not in the reusable schema. HE wants an
extension to the rule
to say if smth is in another schema and it is using these prefixes then they
are reserved.
EG: I don't understand why we don't have rules that says Order is reused for
purchase orders etc and cannot be used in any other context. Why do we have
a rule
for this.
MC: I would understand this rule if we were declaring this locally to ensure
consistency. But since they are declared globally they will have a single
semantic meaning and the rule is unnecessary.
SG: It is for the sake of the tool that Chee Kai wants this rule.
GS: Code lists will have their own namespaces.
MC: So we are agreed that AttributeFormDefault=Unqualified
Agreed.

Issue 16
Schema importation. This may be SSM6-7.
MHC: The main problem according to Chee-Kai is that it is too restrictive.
EG: I don't remember what the motivation for what is there.
LS: I wonder if we have wording around the old rules in the original
document.
Why can't you just import the module you need instead of the entire root
schema.
BB: The idea was to build encapsulated modules for components. We wanted
these components to have well defined boundaries.
If there was circularity then you don't have independent components.
EG: I think it is hard to implement.
BB: We did not prescribe that there needed to be automatic checking.
EG: The question is the way it was originally expressed that this was a
design principle rather than a rule.
MHC: My idea is that it is a rule.
EG: Chee Kai's problem is the auto-checking for circularity I think.
EG: There are 2 things confused inhis note. One is circularity and the other
is repetition. Theoretically they are separate.
SG: Can you really say the RT scheam and the CCT schema are truly modular.
If the RT schema depends on the CCT schema. Does this
not break the rule?
GS: Yes, but it is a workaround.
GS: SSM6-7 impacts the reusable types and BIEs only not RTs and CCT schemas.
EG: So we have a design problem with the code list schema.
GS: The code list schema is not based on the RT schema. It will be based on
the CCT schema.



The following items were provided by Stephen Green so I want to go through
them quickly.
4. The rule about the element and type needing annotations for their
declarations was, I believe, wrongly changed at the last meeting. The
original rule was correct in that the representation term, etc are different
for a type (based on an ABIE) as for an element (based on a corresponding
ASBIE, or less relevant, based on a BBIE). The misunderstanding was made in
thinking that the rule wasn't being kept when in fact all elements and types
did have these annotations in one place (but only in one place) already.
People would need to look at the schemas to see this - if I try explaining
it it might not be so clear.

EG: We made a change to accomodate current practice as we thought it was.
Current practice was what the original rule said.
MC: The annotation requirements are different depending on whether they are
BBIEs and ABIEs. The current rule can not be applied against both.
We will need a rule for a CT based on ABIE, a BBIE, an element based on an
ASBIE.
MHC: Mark will sit down with CCTS and write them.
MC: The issue is one of conformance to the rule by LC.
We don't need to change this for the beta. Someone will have to populate the
columns in the spreadsheet for the beta release.
LS: We need to hold their hands and give them examples.
MC: It is real easy here.
We put the context in the spreadsheet, when the default value of In all
context applies it does not need to in the schema.
If the value inthe spreadsheet is in all context, it is not included in the
documentation element in the schema. It will only appear in the schema
if it is not the default value.
Unanimously agreed.


5. It was ruled that the schema locations should be absolute but with a
comment from Mark that LC might just want to keep this for the final release
rather than for the beta too. LC have asked that it be clarified that this
is OK. There would be some difficulty in trying to use an absolute path
during development for the beta and then for the beta itself so they wish to
use relative paths in the beta release.

SG: We do not have an absolute path. During development we have many
iterations.
BB: It seems that we would want to test this in the beta and we would need
to test this with Oasis. This is rule
ATD8.
MHC: We want to make our URLs resolvable through the Oasis web server. Who
do we need to talk to?
MC: ATD7 talks about URLs.
EG: We can use urns for namespaces for schema locations we should use urls.
The contact for preparing directories is Sharon Burbine.
MHC: I think we need to test this for the beta.
GS: We can test this with a relative path. We just need a location and we
can do this relatively.
EG: Why do we have this rule.
BB: We believed the XSD spec that said schema location is just a hint, and
that there would be a way to map those absolute schema locations to a lcoal
repository.
Is this repository mapping feature for real.
EG: The alternative would be to have it as a relative and do it locally at
all times. Not everyone can do it remotely at all times.
Realistically to assume that this will work is wrong. Set the schema
location to a relative path and publish where they are available in Oasis.
I move that this rule be changed to use relative paths (ATD8). The schema
location value MUST be relative and the documentation must have the absolute
path
saying where to get the schemas from.
MC: ATD 8 changes to relative. We are adding a new documentation rule.
Unanimously agreed.

BB: This is defined in NMS6
6. LC wanted it flagged up that they will, with Gunther's suggestion, be
dropping the datatype schema from the beta release since it is not used and
could confuse. I think that really the rule should reflect this - that the
DataType schema is not required unless CCTS datatypes are actually used.
MC: Do we envision that we will ever use this DataType schema module.
GS: Yes in the future because some additional RT will be based on datatypes,
and we can define other datatypes like CountryCode. It is not fixed in our
rules
how we are using datatypes.
MC: If we don't have the datatype then we are in full conformance with the
rule.

7. AOB
None

8. Adjourn



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]