[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of Atlantic UBL TC call 8 December 2004
MINUTES OF THE ATLANTIC UBL TC MEETING
16H00 - 18H00 UTC WEDNESDAY 8 DECEMBER 2004
ATTENDANCE
Jon Bosak (chair)
Marty Burns
Tony Coates
Mark Crawford (vice chair)
Michael Dill
Micah Dubinko
Jessica Glace
Betty Harvey
Anne Hendry
Marion Royal
Ken Sall
Sylvia Webb
STANDING ITEMS
Additions to the calendar
(http://ibiblio.org/bosak/ubl/calendar.htm)
None.
Event reports
JonB: Gave the usual UBL status report at the November ISO
IEC ITU UNECE MoU/MG meeting hosted by Sun in Burlington
(UBL has been on the continuing agenda of the MoU/MG for
three years now). Met with OASIS, UN/CEFACT, UNECE, and ISO
representatives in an evening session and reported back to
the MoU/MG that we are attempting to formulate a plan to
converge UBL with UNTDED and UNeDocs, which is headed for
incorporation into UN/CEFACT next year, with the intention
of eventually producing a single document-oriented UN/CEFACT
deliverable, but that the technical feasability of this idea
would need to be investigated before a concrete plan could
be put before the various groups involved. Am hoping that
such a plan could be put before the UBL TC at our meeting in
Washington the week of 31 January.
JonB: Gave two presentations at the November EIDX meeting
hosted by Sun in Menlo Park. Also organized and chaired a
session on Semantic Harmonization that featured
presentations on UDEF, ebXML CCTS, and Ontologies; the
slides and a recording of the presentations and the panel
discussion that followed are linked from Peter Yim's wiki at
http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2004_12_01
Liaison reports (if any)
MarionR: TBG17 making progress; nothing for the minutes.
Subcommittee reports (if any)
AnneH: SSC: DavidK took StephenG's spreadsheets, round
tripped them, and reported diffs that the SSC is now
evaluating and will discuss in meeting tomorrow.
MicahD: HISC: Brief meeting yesterday, but no quorum; will
send email report to HISC list.
Team reports (if any)
None.
ISSUES FOR DISCUSSION THIS MEETING
Initial discussion concentrated on dividing up responsibility
for disposition of the issues identified by the SSC (see the
agenda for this meeting).
Code list issues
The issues listed under this heading in the meeting agenda are
for the information of the CL team: these are the current (1.0)
NDRs relating to code lists. Functionally, we need to know as
soon as possible which of these will change in 1.1. (The code
lists published in 1.0 also need some content fixes, but this
is being taken care of in SSC.)
The basic CL question is what to do about code list
extensibility; some people consider this a key requirement and
have proposed substitution groups as a mechanism for supporting
it, while others object to substitution groups and have
questioned the need for this level of extensibility. To move
ahead, the CL team needs (a) responses to the 1.0 CL spec and
(b) a clarification of the extensibility requirements.
Agreed: We need to be clear on what extensibility is and
whether it's needed. The CL team is currently reviewing a
reformulation of the requirements that can be presented for
comments. TonyC will review a draft of requirements, then
MartyB will produce a document by Xmas for review by MarkC
(with a copy to the ubl list) and will confer with MarkC the
week after Xmas. We note that MarkC leaves for the ATG meeting
in Sydney 1/5 or 1/6.
Agreed: The revised CL proposal must include revisions (if any)
to the 1.0 CL NDRs.
Agreed: GEFEG will not undertake changes to EF until such
changes have been reviewed by the NDR team and then approved by
the TC.
NDR issues
Agreed: We will start using the TC meeting format we decided on
in Menlo Park by holding an NDR working session during the
second hour of next week's Atlantic TC call. The NDR team will
consist of MavisC, MarkC, MikeG, BettyH, and KenS; KenS will
put the NDR issues in a spreadsheet like the one previously
used for 1.0 NDR issues. MarkC may not be available for the
first hour of the TC meeting but should be able to participate
in the NDR work session.
JonB to check with Mavis to see whether she will be available
to lead the discussion next week.
Remaining issues (see agenda for this meeting)
The following applies to UBL-CoreComponentTypes (issues 4-7)
and UBL-UnspecializedDatatypes (issue 4):
Agreed: We will adopt the ATG CCT schemas; the question is
when (1.1 or 2.0).
MarkC: The ATG CCTS schemas are essentially cooked. Many
(perhaps all) of the issues raised by UBL have been disposed
of. Agreement has been reached with OAG, now ATG just needs
feedback from UBL regarding the result. The ATG schemas are
going out for implementation verification in the next week
or two; UBL needs to see whether it can be implemented in
1.1 or will have to wait for 2.0.
AnneH: We suspect it will be 2.0.
Agreed: We will expect in the next week or two to receive
the proposed CCT and UDT schemas, plus a proposal from
GarretM regarding the creation of a normative specialized DT
schema module that incorporates the balance of the XSD
built-in data types not already accommodated.
UBL-SpecializedDatatypes (issue 5)
Agreed (with regard to the credits): It's our understanding
that ISO has declared the code lists legally usable by UBL
and similar initiatives; so it appears to be unnecessary to
change the current CL schemas in this regard.
AnneH: Prefix, definition, etc. are not supplemental
components in CCTS. We need a way to store these. TimM is
working on this, but we're not sure whether it needs to be
in EF (it probably does if the data is to appear in the
spreadsheets generated by EF). The question is, how do we
extend the model. This is independent of the ATG CCT
modules.
Agreed: This is an issue for discussion by a Library Content
team. We therefore need to set that team up. We propose
TimM as lead, with assistance from StephenG, AnneH,
JessicaG, and BettyH; meetings should take place starting
around 00h30 UTC (19h30 in Washington, 08h30 in Perth),
avoiding Wednesday and Thursday evenings in Washington
(Thursday and Friday mornings in Perth).
UBL-SpecializedDatatypes (issue 6)
Agreed: Decisions made today have taken care of this.
Spreadsheets - General - issue 2: [DOC2]
JonB (summarizing some preliminary discussion): This NDR
applies in 1.0 only when the schemas are customized, but may
apply to us in 1.1 or later.
AnneH and MarkC: But this also applies to code lists,
because an enumeration is a kind of restriction.
JonB: Have some trouble accepting this line of reasoning;
what would not constitute an implicit restriction?
MarkC and KenS: We can solve this by viewing the enumeration
itself as the documentation.
Agreed: The NDR team will change the rule to except
enumeration restrictions.
Spreadsheets - General - issue 3: registration
MichaelD sent the BIEs in XMI form to Farrukh, but we're not
clear where this stands. It's not clear whether this should
be pursued with the ad hoc group in the OASIS RegRep TC or
with the OASIS eGov TC. We will pick up again at this place
in the issues list during the first hour of next week's
Atlantic call.
The meeting ended here; we will continue next week with the
following.
==================================================================
REMAINING ISSUES FOR THE FIRST HOUR OF NEXT WEEK'S CALL
==================================================================
4. [GNR1] UBL XML element, attribute and type names MUST be in the
English language, using the primary English spellings
provided in the Oxford English Dictionary.
Actions/Questions for TC:
- Check SS(s) element, attribute, and type names.
5. [GNR4] - [GNR6] Acronyms and Abbreviations
EF checks against NDR, but if acronym is in SS it is left alone.
Actions/Questions for TC:
- Resolve A&A list, usage, ownership, and maintenance.
- Align SS and Schemas with final list and rules.
Mark, 20041106:
The candidates need to be discussed by the entire TC once the
list is made. Remember, it must be globally unique to be
considered. We have already violated this tenant with
non-globally unique acronyms and must exercise greater
diligence in the future.
6. [GNR7] UBL XML element, attribute and type names MUST be in
singular form unless the concept itself is plural.
Actions/Questions for TC:
- Check SS for conformance.
7. [ATN1] Each CCT:SupplementaryComponent xsd:attribute "name" MUST
be the Dictionary Entry Name object class, property term and
representation term of the ccts:SupplementaryComponent with the
separators removed.
If the object class is identical to the RT of the data type
(or cct or whatever) then UBL removes the Object Class from the
name. EF and SS do the same thing, which is different than what
it says in this rule. ELN3 covers elements, but not attributes.
Actions/Questions for TC:
- Review rule for SS UBL name creation.
- See NDR section below for ATN1 rule update
Schema - General:
1. [GXS1] UBL Schema MUST conform to the following physical layout ...
UBL schema organization is different than GSX1:
- short copyright not the same
- full copyright should be at end of document
- need to align order for declaration of namespaces
and order of imports and follow structure outlined in GSX1
- include section head comment lines, except when section is
empty
GXS1 doesn't include, but UBL comment header currently does include:
- "Universal Business Language (UBL) Schema 1.0"
- URLs to UBL and OASIS web sites
- "Document Type"
- "Generated On" (date)
- tribute to Mike
- additional comment lines for additional clarity
Actions/Questions for TC:
- Review schema layout/format
- Update schemas to agreed layout.
- Change rule accordingly for 1.1
2. [NMC1] Each dictionary entry name MUST define one and only one
fuly qualified path (FQP) for an element or attribute.
EF doesn't explicitly check this, nor duplicate DEN's/names
for objects.
Mark, 20041106:
Remember – FQP as the DEN not CCTS defined DEN
Actions/Questions for TC:
- Clarify whether there's need for EF to explicity check this.
3. [VER1] - [VER7] Relating to use of major/minor version numbers.
---------------
There is nothing in EF to automatically create version numbers.
Now it is done manually; should EF consider automating this?
Mark, 20041106:
This is more than an EF issue. We are also somewhat limited by EF’s
non-registry/non-database approach. We need to decide how we are going
to handle versioning of individual components in the spreadsheet.
Actions/Questions for TC:
- Decide on versioning implementation.
- Decide on strategy for storage/registry.
4. [DOC1] The xsd:documentation element for every Datatype MUST
contain a structured set of annotations in the following
sequence and pattern:
• ComponentType (mandatory): The type of component to which
the object belongs. For Datatypes this must be “DT”.
• DictionaryEntryName (mandatory): The official name of a
Datatype.
• Version (optional): An indication of the evolution over
time of the Datatype.
• Definition (mandatory): The semantic meaning of a Datatype.
• ObjectClassQualifier (optional): The qualifier for the
object class.
• ObjectClass(optional): The Object Class represented by
the Datatype.
• RepresentationTerm (mandatory): A Representation Term
is an element of the name which describes the form
in which the property is represented.
• DataTypeQualifier (optional): semantically meaningful
name that differentiates the Datatype from its underlying
Core Component Type.
• DataType (optional): Defines the underlying Core Component
Type.
UBL supplies only the mandatory set (ComponentType, DEN,
Definition and RepresentationTerm). Even though the SS have
Object Class and Object Class Qualifier, EF can't create these
optional information items because no rules in ccts.
Stems from same problem described in UDT section #5.
Mark, 20041106:
Not sure I understand the EF constraint here.
Actions/Questions for TC:
- Resolve gaps in CCTS for naming requirements for SS/EF.
5. [DOC2] A Datatype definition MAY contain one or more Content
Component Restrictions to provide additional information
on the relationship between the Datatype and its
corresponding Core Component Type. If used, the Content
Component Restrictions must contain a structured set of
annotations in the following patterns:
• RestrictionType (mandatory): Defines the type of
format restriction that applies to the Content Component.
• RestrictionValue (mandatory): The actual value of the
format restriction that applies to the Content Component.
• ExpressionType (optional): Defines the type of the regular
expression of the restriction value.
See Table 7-1 of CCTS. Examples of a CC RestrictionType
for, say, 'String' type would be 'minimum length'.
The RestrictionValue would be the actual value.
There must be the above structured set of annotations
for each restriction.
Currently UBL has no documentation for Content Components
or Supplementary Components.
Actions/Questions for TC:
- Review implementation to see if we should be adding anything.
==================================================================
NDR ISSUES FOR THE SECOND HOUR OF NEXT WEEK'S CALL
==================================================================
1. [GXS6] The xsd:final attribute MUST be used to control extensions
AIs:
+ 1.1: Recommend to remove as this is already an xsd tenet.
No need to restate here and confusing where to apply.
Or possibly move to CM document.
Mark, 20041106:
This rule was originally left in because it was internal guidance
for development of the extension methodology. There is no requirement
to use xsd:final in xsd – it is just available for use. The extension
methodology folks could just have easily said that “the annotation
documentation element will contain detailed guidance on which element
should be considered the “final” element for controlling extensions..”
I recommend the rule remains as is.
2.
[SSM10] The ubl:CommonAggregateComponents schema module MUST
be named “ubl:CommonAggregateComponents Schema Module”
[SSM12] The ubl:CommonBasicComponents schema module MUST
be named “ubl:CommonBasicComponents Schema Module”
[SSM14] The ccts:CoreComponentType schema module MUST
be named “ccts:CoreComponentType Schema Module”
[SSM17] The ccts:UnspecialisedDatatype schema module MUST
be named “ccts:UnspecialisedDatatype Schema Module”
[SSM19] The ubl:SpecialisedDatatypes schema module MUST
be named “ubl:SpecialisedDatatypes schema module”
AIs:
+ 1.1: Need NDR clarification on where these terms are to be used.
Mark, 20041106:
Concur.
+ 1.1: The plurality of the word 'Type' in the module name for
SSM19 doesn't agree with that of of SSM14 and SSM17.
UBL implements this word as a plural for all 3 cases
(agrees with SSM19, but not SSM14 or SSM17).
Need alignment of rules.
Mark, 20041106:
I would have preferred that UBL implemented in conformance to
SSM14 and SSM17.
+ 1.1: Should there be rules for the CCP also?
Mark, 20041106:
Yes.
3. [DOC1] The xsd:documentation element for every Datatype MUST
contain a structured set of annotations in the following
sequence and pattern:
• ComponentType (mandatory): The type of component to which
the object belongs. For Datatypes this must be “DT”.
• DictionaryEntryName (mandatory): The official name of a
Datatype.
• Version (optional): An indication of the evolution over
time of the Datatype.
• Definition (mandatory): The semantic meaning of a Datatype.
• ObjectClassQualifier (optional): The qualifier for the
object class.
• ObjectClass(optional): The Object Class represented by
the Datatype.
• RepresentationTerm (mandatory): A Representation Term
is an element of the name which describes the form
in which the property is represented.
• DataTypeQualifier (optional): semantically meaningful
name that differentiates the Datatype from its underlying
Core Component Type.
• DataType (optional): Defines the underlying Core Component
Type.
AIs:
+ 1.1: Resolve discrepancy between Rule S28 of CCTS, which says that
DTs must include Qualifier Term (mandatory), but DOC1 has it
as 'optional'.
Mark, 20041106:
We have already covered this.
Rule S28 in CCTS is on the “to be fixed” list.
4. [DOC3] A Datatype definition MAY contain one or more Supplementary
Component Restrictions to provide additional information
on the relationship between the Datatype and its corresponding
Core Component Type. If used the Supplementary Component
Restrictions must contain a structured set of annotations
in the following patterns:
• SupplementaryComponentName (mandatory): Identifies the
Supplementary Component on which the restriction applies.
• RestrictionValue (mandatory, repetitive): The actual
value(s) that is (are) valid for the Supplementary Component.
Don't know where to find this information. Not in CCP.
AIs:
+ 1.1: Need clarification/resolution.
Mark, 20041106:
This would be information that is already available for those few
Supplementary Components who have a predefined restriction in CCTS,
or that the library developers would create as part of defining a new SDT.
May require new spreadsheet column to make more readily available for
schema generation.
5. [GNR4] - [GNR6] Acronyms and Abbreviations
Acronym for DUNS not completely specified.
AIs:
+ 1.1: Update DUNS information in Appendix B.
6. [ATN1] Each CCT:SupplementaryComponent xsd:attribute "name" MUST
be the Dictionary Entry Name object class, property term and
representation term of the ccts:SupplementaryComponent with the
separators removed.
If the object class is identical to the RT of the data type
(or cct or whatever) then UBL removes the Object Class from the
name. EF and SS do the same thing, which is different than what
it says in this rule.
AIs:
+ 1.1: Change rule. Something like
"If the Object Class of the Supplementary Component is identical
to the Primary Representation Term of the datatype of the
cctype then the Object Class will be removed."
This is how cct ss, sdt and udt is probably done.
Mark, 20041106:
Not sure I agree with changing the rule. Would like more
discussion/thought on this.
7. [CDL5] The name of each UBL Code List Schema Module MUST be
of the form:
{Owning Organization}{Code List Name}{Code List Schema Module}
UBL uses a completely different naming convention.
Both the code list declaraion and data types are in the
code list schema files now. What should be in a CL file?
There was intended to be a section in the schema format
(as per GXS1) for code lists but this is not there right now
- somehow gone. The CDL5 name relates to any time where you
must refer to the code list, such as in the header or comments
of the Code List or other schema files or documentation.
It probably would be best to use this for the 'filename'
part of the urn as well, but haven't gone there yet.
Will have to look into this later.
AIs:
+ 1.1: Revisit with new code list model.
Mark, 20041106:
The code list schema modules still need to follow this naming
convention.
8. [CTD1] For every class identified in the UBL model, a named
xsd:complexType MUST be defined.
Example: <xsd:complexType name="BuildingNameType">
AIs:
+ 1.1: Clarify 'class'. Should this be BBIE?
Mark, 20041106:
In UBL 1.0 NDR we treat BBIE Properties as well as ABIEs as classes.
See the sentence preceeding the rule which explicitly states this.
We may need to separately handle type definitions for BBIE Properties
in UBL 1.1 NDR.
9. [CTD7] Every unspecialised Datatype must be based on a ccts:CCT
represented in the CCT schema module, and must represent
an approved primary or secondary representation term
identified in the CCTS.
AIs:
+ 1.1: Need clarification of what is meant by 'must be based on'.
Mark, 20041106:
Noted.
+ 1.1: Need rule covering case where simple type doesn't restrict
underlying type, but restricts underlying built-in xsd types,
as in UBL. Not all udts are direct restrictions.
Mark, 20041106:
See previous comments regarding adopting CEFACT ATG CCT and UDT schemas
which address this concern.
10. [9.11.04 Anne]
This text appears in the NDR after SSM10:
"By design, ccts:CoreComponentTypes are generic in nature.
As such, restrictions are not appropriate. Such restrictions
will be applied through the application of Datatypes.
Accordingly, the xsd:facet feature must not be used
in the ccts:CCT schema module."
But it seems we do restrict (and extend) our cc types in the
UBL-CoreComponentTypes-1.0.xsd.
AIs:
+ 1.1: Check validity of rule w.r.t UBL implementation.
Mark, 20041106:
Please identify exactly what restrictions/extensions are applied
in the CCT schema module. If not specified in CCTS, then that is
a fatal conformance issue. We also probably need to insert the
word specialized in front of the word datatypes.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]