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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: Minutes August 20 2003


Dear all
please find attached the minutes for this week. Please send regrets for next
week and look at the action items.


Regards
Mavis

-----------------------------------------------------------
1. Roll call and welcome by the chair (Mavis)
Mavis Cournane
Mike Grimley
Jack Gager
Eduardo Gutentag
Sue Probert
Jon Bosak
Bill Burcham
Stephen Green
Lisa Seaburg
quorum achieved.


Regrets:
Mikkel Hippe Bruin
Jessica Glace
Mark Crawford
Tony Coates

Regrets next week
Eduardo Gutentag


2. Containership
Doing containers automated
Doing containers manually
Not doing containers.
LC are putting together samples and a position paper and says we will
probably do it manually.
EG: Are these rules we have developed lately.
LS: Yes
EG: 115c, and 115d makes no sense.
LS: The rule that says everything goes in to a "Top" element breaks
everything.
EG: Manually building in containers does not make sense. It is dependent on
cardinality which is already there.
LS: They say the recursions get too deep.
They are talking real life and we are talking theory.
JB: I thought we came to a joint decision in Montreal.
LS: Yes they were going to do that exercise and come back to us on it.

Discussion will be Sept 9th and Sept 10th jointly between LC and NDR. These
will be Tues 8am PST, Wed 8:30am PST on the 9th and 10th Sept respectively.

EG: I don't understand what 115c and 115d.

[R 115c]  The document element in the schema will have a content model that
is a sequence of elements, the first of which will be the "Top" element, and
the others will be the generated "List" elements, in the order in which
their contained, repeatable children appeared in the model.

SG: That defines the top elements. A and B is to define list. The problem
was we had to come up with something that was auto-generated. Since then it
was decided that human involvement was ok. A human needs to decide what is a
list etc.
The main thing is we already have some containers in the Model e.g.
PartyName within we have Name which is 0 to many. If you had to add NameList
or PartyNameList that just gets silly. That happens quite a few times.
Only half of the possible lists needed to be manually created. There were
other examples where it would be nonsensical to have a list. We would not
want BBIEs to be multiple. We came to the conclusion in Montreal not to have
automatic rule.

EG: Why discuss it then?
SG: The other half of the problem is that we have not looked at the other
possible containers. Now we decided we can do them manually there aer alot
of possibilities for other containers. AUtomatically, we could only have one
container. Now we can look at grouping things together. We could have a head
container that puts all the common elements in a document together.
EG: The purpose of the joint meeting is to figure out how they can be
replaced by human implementable rules.
JB: I am not sure LC understand that we are not going to tackle this
automatically.
We may need to convey this to LC
MHC: Lisa Seaburg will need to relay this to them.


[R 115a] All non-repeatable BIEs that are direct children of the
document-levelBIE in the model will be child elements of a generated "Top"
element in the schema. The generated "Top" element will be named
"[doctype]Top", and its content model will be a sequence. It will reference
a generated type named"[doctype]TopType". Both the generated "Top" element
and its type will be declared in the same namespace as the document-level
element. (Note: This rule implies that all documents will have generated
"Top" elements, without exception, regardless of their other 'body'
contents, to cover cases where the document will be extended with the
Context mechanism, and for general consistency.)

[R 115b] All repeatable BIEs in the model will have generated containers.
The containers will be named "[name_of_repeatable_element]List". These
containers will be required if the cardinality of their contained immediate
children requires at least one; if their contained children are optional;the
container itself will be optional. At least one of the repeatable children
of the List will always be required, but there may be more than one required
child if that agrees with the cardinality found in the businessmodel.All
"_____List" elements will reference a "_______ListType", which will be
declared in the same namespace as the element that represents the repeatable
BIE in the business model. The content model of this type will have a single
child element, which will have a maximum occurrence that reflects the
maximum occurrence in the business model, and a minimum occurrence as
described in this rule, above.(NOTE: This rule applies equally to 'list'
containers at the document level,and also at lower levels within the
document.)



[R 115d] All elements in the generated schema that are direct children of
the generated "top" elements in all documents should be gathered together
into a common aggregate type, named "TopType", which will be declared in the
CommonAggregate Types namespace. This type should be declared abstract, and
all document headers should be extensions - even if only trivial extensions
to facilitate re-naming - of this abstract type. (Note: This rule allows for
polymorphic processing of the set of generic header elements across all
document types.)

3. Review of stuff that requires possible rules e.g
Use of built-in schema attributes for elements not already addressed
including abstract, block, default, final, fixed, form, maxOccurs, minOccurs

- Use of built-in schema attribute 'abstract' for complexTypes
LS: They are all part of attributes for the UR schema.
SG: The idea of the UR schema means you need to support the abstract types.
We don't expect them to appear in 1.0. will these rules only apply to LC and
do we need extra rules for customisation.
EG: The ur schema is a concept not a delieverable. Library will deliver the
real schema and not the UR schema.
SG: Ur would be derived by a rule so you just need to deliver the rule.
Are we going to have to provide NDR rules for customisation.
SP: We talked about Eduardo's guidelines.
EG: These are not rule-based.
EG: The difference between the real schema and ur schema is that whenever
the schema has things that are not optional, the ur schema has them
optional. All complex types in the ur schema complex.
MHC: Are we clear that we are not delivering an ur-schema.
EG: My inclination is to delete this and to delete rule 109
ALL: Agreed with quorum.



Use of Instance attributes nil, noNamespaceSchemaLocation, schema Location,
type



Guidelines for use of All, Sequence, and Choice
Done see rules 16



Use of extension element restrictions on introduction of elements and/or
attributes in complexContent
EG: That relates to CM and was introduced at some point by Dan Vint. There
is little context here.



Use of 'field' to specify XPath note



Use of 'import' and 'include'
EG: That may relate to CM.
LS: It also comes in to codelists.
EG: What does this mean?
LS: The last time we discussed this we said it would be CM.
MHC: We should say that possible rules will evolve naturally with the
development of CM.
ALL: Agreed

Use of 'notation'
Rule exists 114



Use of 'redefine'
EG: I don't see why LC can't use redefine. Our issue with it was namespace.
I can't think why they would want to use it, but we should not stop them?
A rule for redefine is not required for UBL 1.0 as we will not be covering
rules for customisation in the NDR rules for 1.0.


Use of 'restriction' in simple types, in complex types using simple content,
in complex types using complex content.
A rule for redefine is not required for UBL 1.0 as we will not be covering
rules for customisation in the NDR rules for 1.0.
Agreed with quorum


Use of 'schema' (parent element) attributes attributeFormDefault,
blockDefault, elementFormDefault, finalDefault, targetNamespace, version,
xml:lang

EG: If the US government mandates that in all schemas they use must have the
version attribute then we have a problem. If they don't then we don't have a
problem. There are very few versions that have a version.
MHC: We need to investigate this.
ACTION ITEM: Mark Crawford to investigate if version is mandated on all
schemas used by the government whether their own or external ones.
Lisa Seaburg says that they are mandating this.
EG: You can't add a version attribute without changing the UBL namespace.
SG: I am guessing that such rules would not apply to external schemas.

EG: I would not talk about xml:lang that is an XML thing.
xml:lang is an xml feature not an XSD feature.
For XML features we don't need rules. Agreed with quorum.

attributeFormDefault
SG: LC would value some input, should it be elements qualified, attributes
unqualified by default. At the moment the schemas look bloated. Without the
rule for elements you have to pre-fix every element.
ACTION: SG to ask Chai-Kai for use case and a proposal for what is wanted.

blockDefault
MHC: We need an example and will ask Tony Coates if he wants anything for
this.

Use of 'selector'
This is part of Key/Keyref and needed for it. Already covered by implication

Use of 'simpleType' 'final' attribute
LS: This is out of scope as we are not using substitution groups at this
point.



Any restrictions on the use of 'union' technique and its 'memberTypes'
attribute
There is a guideline for this in codelists but under normal use it is
prohibited. Rule 100



Use of 'unique'
There was a decision with LC in London not to use unique id
MHC: THis is customisation and out of scope.



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