Re: [ubl-ndrsc] Minutes UBL NDR SC October 15 2003

[Eduardo Gutentag <Eduardo.Gutentag@Sun.COM>]

Regarding

 > 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.

I thought we had agreed that we would only mark those rules which
do not apply for the beta release, not the other way round (mark
those which do apply to beta and which do apply to final)

Mavis Cournane wrote:
> 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
> 
> 
> 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_workgroup.php.
> 

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
Sun Microsystems Inc.          |
W3C AC Rep / OASIS BoD