[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SSC Agenda, 2 December 2004
The UBL Software Subcommittee will meet on 2 December 2004
The Atlantic call will occur at 17H00 - 18H00 UTC :
09h00 - 10h00 Thursday San Francisco
12h00 - 13h00 Thursday Washington
17h00 - 18h00 Thursday London
1h00 - 2h00 Friday Singapore
http://www.timeanddate.com/worldclock/fixedtime.html?day=2&month=12&year=2004&hour=17&min=0&sec=0&p1=0
** The Pacific call will not be held this week. **
However, in the last meeting we agreed to hold
the Pacific call at the daylight savings time
(keeping the hours the same for the Pacific folks).
This will start next week, then.
#############################################
STANDING INFORMATION FOR UBL CONFERENCE CALLS
U.S. domestic toll-free number: (866)839-8145
Int. access/caller paid number: (865)524-6352
Access code: 5705229
#############################################
Agenda:
1. Welcome new members:
Betty Harvey
Ken Sall
2. Continued review of AIs from EF/SS alignment.
Sorry, but we're still on this. I think what we can review now,
at least, is the disposition of the changes for the alignment test,
which I last had at:
Changes made to Spreadsheets for alignment testing:
(See http://oasis-open.org/archives/ubl-ssc/200411/msg00009.html)
- Replaced CodeListURI trailing space with special SPACE character.
- EF alignment: Removed 'format' attribute from UDT/CCT NumericType.
+ EF alignment: Removed UBL-specific codelist attributes
(prefixid, desc, credits) from the SDT SS and put
these values in two new columns at the end named
'Code List Schema Prefix' and 'Content Definition'.
'Credits' information was not kept.
+ EF alignment: Remove value from 'value' column of 'name' row(s)
in SDT.
+ EF alignment: Updated UDT SS BinaryObject secondary representation
terms to only have 'Content' and characterSetCode'.
Still to be done to SS for alignment testing?
+ EF alignment: Remove trailing space from SDT spreadsheet CodeListURI.
+ EF alignment: Change CCT/UDT/SDT spreadsheets to use 'Content' value.
And confirm changes to EF thus far.
3. Other remaining issues and disposition from last meeting:
+ EF alignment: Complete SDT import functionality.
+ EF alignment: David explain how the names for CCs and SCs
for secondary RTs are currently generated by EF.
+ 1.0.1: Remove trailing space from SDT spreadsheet.
+ 1.0.1: Add white space trimming in EF.
+ 1.0.1: Remove format attribute from spreadsheet NumericType.
+ 1.1: EF suggest other way to model secondary RTs.
+ 1.1: Change CCT and UDT spreadsheet to use 'Content' value.
+ 1.1: Fix order of the supplementary components in CCT/UDT/SDT
for "Code. Type" and "Identifier. Type"in SS.
[Also, neither schema nor ss are in CCTS order for
BinaryObjectType.]
+ 1.1: Find out if EF can preserve extra ss information (columns, etc).
+ 1.1: Decide if we need UBL-specific code list attributes (eg.
codeListNamespacePrefixID, codeListDescription, CodeListCredits)
+ 1.1: Figure out a better way to represent additional CodeList
attributes. EF suggests columns for these.
+ 1.1: Need to align SDT SS, Codelist model and EF import ability.
Dependency on completion of Codelist model.
+ 1.1: GEFEG provide list of the columns from the TBG17 SS they want
to see in the UBL SS.
+ 1.1: Review schema format (GSX1).
+ 1.1: Update schemas for GSX1.
+ 1.1: Resolve gaps in CCTS for naming requirements for SS/EF.
+ 1.1: ELN4 conformance - Check that SS/EF follow rule
+ 1.1: DOC3 conformance
+ 1.1: respond to Mark's comment on ATN1.
+ 1.1: Check validity of SSM10 rule w.r.t UBL implementation.
(NDR issue #10)
4. Disposition of the issues/questions we raised at the F2F.
I've attached the full list with latest comments and perhaps we
can close some of these as I know they've been resolved (some are noted).
5. Other business
The SSC F2F discussions focused on reviewing Spreadsheets, Schemas,
EDIFIX, and the NDRs to discover alignment issues, resulting in
proposals for changes to be considered for future development.
We arrived at 5 basic categories/timeframes of needed changes:
a) 1.0 Release Notes
b) EDIFIX alignment testing
c) 1.01 update
d) 1.1 update
e) 2.0 issues
Below is a summary report by area and issue, noting actions for each
of the above categories/timeframes, also indicating areas that need
full TC review (indicated by "TC->" in margin).
----------------------
UBL-CoreComponentTypes
----------------------
1. The 'Component Type' spreadsheet column (column X) needs to
distinguish 'content' components from 'supplementary' components.
So possible values for this column will be one of:
"CCT", "Content", or "Supplementary"
AIs:
+ EF alignment: Change CCT spreadsheet to use 'Content' value.
+ 1.1: Change CCT spreadsheet to use 'Content' value.
20041117 TC:
Mark, 20041106:
I am not sure I understand this. The content component is fixed
for each CCT in the specification and the content it conveys is
driven at the time an instance is created.
2. The order of the supplementary components for "Code. Type" and
"Identifier. Type" should be aligned with the one used in the
CCT schema and in CCTS 2.01. [** Also, neither schema nor ss
are in CCTS order for BinaryObjectType. **]
AIs:
+ 1.1: Agree to fix in SS. However, UBL will not formalize the
sequence of bbies in the ss model, as those are ordered
for human readability.
20041117 TC:
Mark, 20041106:
Please note that there is no normative order for the supplementary
components. Further, since these are attributes, there is no way
to enforce order in the instance. Thus any order in the schema
is purely arbitrary.
3. Need to resolve handling of "Property Term Possessive Noun"
and "Property Term Primary Noun" - EF is only able to store
these entries as user notes. UBL uses them for modeling.
AIs:
+ 1.1: Sylvia find out if EF can preserve those columns
(even if there are values in them, and even if it can't
preserve the values). Then if EF can regenerate those
columns on output (even without the values) we'll just
regenerate the values manually (by adding the formula).
Regardless of how EF manages those columns internally,
the output UBL SS format (columns and column order)
needs to remain as it is in 1.0.
20041117 TC:
Mark, 20041106:
The output needs to be a single property term or property term qualifier.
4. [MDC1] UBL Libraries and Schemas MUST only use ebXML Core Component
approved ccts:CoreComponentTypes.
The UBL CCT schema implements ebXML approved cctypes according
to CCTS Table 8-1, with three exceptions: numeric, datetime,
and indicator. The UBL CCT schemas do not contain the 'format'
attribute for these three types. These have been cast as
'simple' types (which precludes adding more attributes).
AIs:
TC-> + 1.0 Release Notes: Format attribute in ss but not schema.
+ 1.0.1: Remove format attribute from spreadsheet NumericType.
TC-> + 1.1: Consider the impact of the fact that we have removed the
'format' attribute and constrained these as simple types.
Is this really how we want these represented in the future?
20041117 TC:
Mark, 20041106:
This is one of the reasons why we should follow the CEFACT solution.
CEFACT ATG has created a CCT normative schema that only consists
of complex types. Each supplementary component is represented by
an attribute so there is a perfect match between CCTS and the CCT
schema module. CEFACT ATG then creates a separate and distinct
unqualified datatype schema module that “is based on” the CCT
schema module rather than importing it. In the UDT schema module,
we define both complex and simple types similar to how UBL does
in the CCT schema module. In this fashion we are able to have
a pure CCT schema module and an XML instantiated unqualified
datatype module.
Tim, 20041107: Have a format as a property of numeric and date and
a couple of others is that because that's what's in the table it ccts.
If not in the model then we're not compliant. Confusion is that
if in model doesn't need to be in schema. Not every piece of info
in model has to be in schema. Tend to work backwards from schema
to decide what has to be in model. But need some way to determine
what is in model that shouldn't go in schema. Don't have way to
do this in tool.
Gunther removed format because xsd has way of doing this automatically.
NDR agreed to this. But this diesn't hinder it's appearance in the model.
If it does appear in the model, though, then it should be implemented
in the schema in a different way.
Conceptual model that ubl follows is that of ccts, so everything in
ccts has a 1:1 correlation with what appears in model.
If we created a format attribute, then we'd have an ambiguity
with xsd/cct, but this shouldn't be in the cct schema. Probably
better ways that we got to these schemas, ala Gunther, but it's
a bit too late to change now without breaking backward compalibility.
5. The ss and schemas of cctypes are currently quite different
because EF is not reading the CCT spreadsheet - the CCT schema
is generated manually as was originally provided by Gunther.
AIs:
TC-> + 1.1: Decide on need for generation of CC Types.
20041117 TC:
Mark, 20041106:
The answer here is to have EF NOT generate the CCT schema module
or the UDT schema module. Rather it is to import the CEFACT UDT
schema module into the UBL SDT schema module.
Tim, 20041107: Obvious concerns: impact on legacy and the fact
that ATG2 has always been a moving target, hence the misalignment
we find ourselves in now, as our current implementation was put
forward as the ATG2 method.
6. [STD1] For every ccts:CCT whose supplementary components map
directly onto the properties of a built-in xsd:Datatype,
the ccts:CCT MUST be defined as a named xsd:simpleType
AIs:
TC-> 1.1/ 2.0: CCTypes schema originally done by Gunther and Garret.
As UBL develops more ccts and rts, will drive the need
for more dts. Need for analysis of new ccts, looking at
available built-in dts to see if one meets the
requirements. Currently ATG does this. Need to decide
whether there is a need for UBL to continue to provide
a cc types schema.
20041117 TC:
Mark, 20041106:
See previous comments. Further, if UBL requires a new CCT or UDT,
it must submit those to, and get approval from, the specification
authority before using them.
7. [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.
In UBL, simple type doesn't restrict underlying the cct, but
restricts directly the buil-int xsd types. Not all udts are
direct restrictions. This rule doesn't provide for this.
Basically there is a difference in approach between two atg and
ubl: in ubl, the udt schema module directly imports the cct shcema
module and every dt has a direct 1:1 realtionship with its
corersponding cct. In ATG, to make (EF) tool development easier,
every cct is defined as a complex type and every sc is present
as an attribute of that cct. Then, also to levearege buil-in dts,
there had to be a break in the direct link between cct and udt
(because you can't turn a complex type into a simple type).
So that is what is meant by saying the constructs in udt are
'based on' cct. Some are simple types where as others are facets
of built-in xsd dt representations.
TC-> AI: 1.1/2.0: Need resolution on CCTypes in UBL.
20041117 TC:
Mark, 20041106:
See my previous comments.
--------------------------
UBL-UnspecializedDatatypes
--------------------------
1. The 'Component Type' column (column X) needs to distinguish
'content' components from 'supplementary' components.
So possible values for this column will be one of:
"DT", "Content", or "Supplementary"
AIs:
+ EF alignment: Change UDT spreadsheet to use 'Content' value.
+ 1.1: Change UDT spreadsheet to use 'Content' value.
20041117 TC:
Mark, 20041106:
See my previous comments.
2. Same as #2 above.
20041117 TC:
Mark, 20041106:
See my previous comments.
3. Same as #3 above.
20041117 TC:
Mark, 20041106:
See my previous comments.
4. "Binary Object", and its secondary representation terms
("GraphicType", "PictureType", "SoundType", and "VideoType")
have "format" and "mimeCode" attributes in the spreadsheets,
but are missing these attributes in the schemas, which instead
have one attribute "characterSetCode".
[** CCTS has additional attributes of filename, encodingcode,
and uri which are missing in both udt ss and schema. **]
AIs:
+ EF alignment: only have 'Content' and characterSetCode' in SS.
TC-> + 1.1: Figure out which of these attributes we want to include
in the long term.
Tim: ok if we only have some in UDT, since all are in CCT.
20041117 TC:
Mark, 20041106:
See my previous comments.
The UDT schema module is incorrect if it does not have all of the
supplementary components declared as attributes. There is no
requirement to use them, but they must be declared by definition.
If UBL does not want the attribute available for use, then they
must create a specialized data type.
Tim, 20041107: This was decided by Garret. We don't use them.
We've taken the idea from OAG.
5. CCTS 2.01 doesn't specify how to generate Dictionary Entry Names
for Supplementary Components of Secondary Representation Terms.
UBL has implemented the Supplementary Components for both
Primary and Secondary Representation Terms as components
of Unspecialized Datatypes following the same naming rules
as for CCTs (and CCs and BIEs). That is the ISO 11179
ObjectClass+PropertyTerm+RepTerm and seems a logical approach.
UBL models Secondary Representation Terms (Graphic, Video,
Date, Time, etc.) as being of the same Object Class as their
respective Primary Representation Term, but with the Object
Class qualified by their respective Secondary RT name.
Example: Graphic type is of object class 'binary object'
with an object class qualifier of 'graphic'.
EF handles unspecialized DTs as unqualified DTs and so
doesn't expect an object class 'qualifier' for these DTs.
In EF, unqualified DT components should not have an Object
Class Qualifier, and EF has no way to store qualifiers of
'unqualified' DTs. So that information is not being used
in the schemas.
Because of this EF has problems creating the Dictionary Entry
Names for Supplementary Components of unspecialized DTs that
represent a Secondary Representation term because it doesn't
use Primary RT rules for these. So EF disregards the qualifier
and uses the Secondary RT type name as the name, as it would
for a Primary RT (Graphic SCs would be prefixed with 'Graphic').
AIs:
+ EF alignment: David explain how the names for CCs and SCs
for secondary RTs are currently generated by EF.
+ 1.1: EF suggest other way to model secondary RTs.
20041117 TC:
Mark, 20041106:
This is an extension of the specification and should not be allowed.
If UBL feels strongly about this, then they should submit a request
for change to CCTS.
Anne: David has updated EF to do what is done in the models.
Tim: We could take this to CCTS as an addendum/enhancement.
20041118 David:
GEFEG will implement the qualifier for secondary representation terms
and will be able to handle the names of Supplementaries as Dictionary
Entry Names.
RESOLVED.
TC-> + 1.1: We need to resolve this difference in naming of SCs of
Secondary RTs. If we determine we need DENs for these
Supplementary Components then we should agree on how
best to model these and what rules should be applied
for their naming, as there are currently no rules for
DEN creation of Content Components and Supplementary
Components of Secondary RTs in CCTS or UBL. We need
a UBL rule (not NDR) which would be an implementation
of the CCTS naming of Secondary Representation Terms.
Should here try to align this with the ATG2 expression
of what they call the UDTs. Tim will look at this.
Tim, 20041117: Original comments on the alignment of ATG2 CCT
schemas and UBL 1.0 ones can be found at:
http://lists.oasis-open.org/archives/ubl/200409/msg00000.html
However, some of this is now history as the ATG2
group have been revising their draft schemas.
For exmaple, i have been informed that some of these
comments (such as the naming of attributes) are resolved.
My personal opinion is that we should aim to have one
definitive set of schemas (owned by ATG2) for UBL 2.0.
The caveat on this is that we have to support backward
compatibility with UBL 1.0 documents (Tim's personal
viewpoint). So in the interim we need to work towards
convergence both with the ATG2 (and OAG) schemas as
they develop.
6. Same as CCT section #4 above.
------------------------
UBL-SpecializedDatatypes
------------------------
1. Same as #1 above.
2. Same as #2 above.
3. Same as #3 above.
4. There is a trailing space in the value for the codeListURI fixed
attribute of the Country codelist.
It would be preferrable for EF to add a feature to do general
trimming of white space (doesn't do this right now) and we must
fix the SS.
AIs:
TC-> + 1.0 Release Notes: problem with trailing space in the value for
the codeListURI fixed attribute of the CountryIdentificaton
Code codelist in both the SDT spreadsheet and schema. (This
effects validity of instances so people should know about it.)
+ EF alignment: Remove trailing space from SDT spreadsheet.
+ 1.0.1: Remove trailing space from SDT spreadsheet.
+ 1.0.1: Add white space trimming in EF.
5. Three attributes used for each of the code types in the spreadsheet
(codeListNamespacePrefixID, codeListDescription, CodeListCredits)
are not represented in the schemas.
AIs:
+ EF alignment: Depending on 1.1 decision, remove UBL-specific
codelist attributes (prefixid, desc, credits) from SS.
TC-> + 1.1: Decide if we need UBL-specific code list attributes (eg.
codeListNamespacePrefixID, codeListDescription, CodeListCredits)
TC-> + 1.1: Figure out a better way to represent additional CodeList
attributes. EF suggests columns for these.
20041117 TC:
Mark, 20041106:
Not allowed as an extension to CCTS. If UBL feels these additional
supplementary components are required, then they need to be submitted to,
and approved by, the specification owner.
Tim: This is more useful pieces of information, both for modeling
and for other reasons (eg. credits). Just becasue they don't fall
into a schema construct doens't mean we should get rid of them.
We used to have them in the comments, not in the actual data.
There should still be allowances for this.
6. The SDT spreadsheet incorrectly has the codelist text file
filename for the "Name" attribute, "Values" column, value.
EF doesn't currenlty use the sdt spreadsheet at all.
Work is underway in GEFEG to be able to improve the algorithm
for importing SDT SS values. Will be done in a couple of weeks.
AIs:
+ EF alignment: Remove value from 'name' row(s) in SDT SS.
+ EF alignment: Complete SDT import functionality.
TC-> + 1.1: Need to align SDT SS, Codelist model and EF import ability.
Dependency on completion of Codelist model.
------------------------
UBL-Reusable and MainDoc
------------------------
1. Because CCTS 2.01 doesn't know a "Property Term Possessive Noun"
and "Property Term Primary Noun" we are only able to store these
entries as user notes.
AIs: Same as #3 above.
Mark, 20041106:
Comment – same as before
David, 20041122:
GEFEG will implement a special model type called "UBL CCTS" or so.
This model type will be able to handle "Property Term Possessive Noun"
and "Property Term Primary Noun".
RESOLVED.
----------------------
Spreadsheets - General
----------------------
1. GEFEG would like the UBL SS at minimum to have the same columns
as the TBG17 SS.
AIs:
+ GEFEG provide list of the columns from the TBG17 SS they want
to see in the UBL SS.
Mark, 20041106:
Absolutely concur.
2. [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.
AIs:
TC-> + 1.1: Review implementation to see if we need to add anything.
Mark, 20041106:
The overall requirement for schema documentation is to provide for
all documentation required by CCTS. This will position the ubl
library as expressed in the spreadsheets to be stored as ebXML
conformant core components.
3. Eventually registration of constructs in schemas should
be automated so can be submitted to registration authority
and metatdata will automatically go into the registristrion
process for the schemas.
AIs:
TC-> + 1.1/2.0: Follow up on registration requirements (CCTS Section 7).
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.
AIs:
TC-> + 1.1: Check SS(s) element, attribute, and type names.
Mark, 20041106:
See comment previous item regarding the need for conformant documentation.
5. [GNR4] - [GNR6] Acronyms and Abbreviations
EF checks against NDR, but if acronym is in SS it is left alone.
AIs:
TC-> + 1.1: Resolve A&A list, usage, ownership, and maintenance.
+ 1.1: 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.
AIs:
TC-> + 1.1: 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.
AIs:
+ 1.1: Review rule for SS UBL name creation.
+ Also see NDR section for rule update
Mark, 20041106:
Not sure I understand exactly what is happening here.
----------------
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
AIs:
TC-> + 1.1: Review format
+ 1.1: update schemas.
Mark, 20041106:
And change rule accordingly for version 1.1
Tim, 20041107:
People should look at rule and schemas.
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.
AIs:
TC-> + 1.1: Clarify whether there's need for EF to explicity check this.
Mark, 20041106:
Remember – FQP as the DEN not CCTS defined DEN
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?
AIs:
TC-> + 1.1: Decide on versioning implementation.
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.
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.
AIs:
TC-> + 1.1: Resolve gaps in CCTS for naming requirements for SS/EF.
Mark, 20041106:
Not sure I fully understand the EF limitation/problem here.
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.
AIs:
TC-> + 1.1: Review implementation to see if we should be adding anything.
6. [ELN4] A UBL global element name based on a qualified
ccts:BBIEProperty MUST be the same as the name of the
corresponding xsd:complexType to which it is bound,
with the qualifier prefixed and with the word "Type" removed.
It could be that there are elements whose names consist of
qualifier property term, property term, and representation
terms that refer to a complex type with the name having
only the property term and representation term.
AIs:
+ 1.1: David check correctness of above statement of current situation.
+ 1.1: Check that SS/EF follow rule.
Mark, 20041106:
I am not sure I understand the issue – is it with the rule or with
what we implemented?
David, 20041122: EDIFIX definitely follows the rule.
RESOLVED.
7. [10.11.04 Anne]
Regarding
[DOC4] The xsd:documentation element for every Basic Business
Information Entity MUST contain a structured set of
annotations in the following patterns:
• ComponentType (mandatory): The type of component to which
the object belongs. For Basic Business Information Entities
this must be “BBIE”.
• DictionaryEntryName (mandatory): The official name of a
Basic Business Information Entity.
• Version (optional): An indication of the evolution over
time of the Basic Business Information Entity.
• Definition(mandatory): The semantic meaning of a Basic
Business Information Entity.
I don't see that we have any documentation for our BBIEs,
at least not in the CBC schema. Is this where it would be?
AIs:
+ 1.1: Check documentation for BBIEs.
Mark, 20041106:
There are no BBIEs in the CBC schema. There are BBIE properties.
BBIE property documentation should occur in the CBC schema,
but we did not write a rule for this (NDR oversight)
(BBIE properties have one optional and one mandatory attribute:
Qualifier Term (optional) and Cardinality (Manditory).
The BBIEs are realized in the form of refs in the CT definitions
in the CAC schema and BBIE documentation should appear there in
accordance with rule [DOC4].
---
NDR
---
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.
---------
Code List
---------
Revisit all rules below and any others in NDR when new Code List
model is available.
1. [CTD17] Each ccts:SupplementaryComponent xsd:attribute
user-defined xsd:simpleType MUST only be used when the
ccts:SupplementaryComponent is based on a standardized
code list for which a UBL conformant code list schema
module has been created.
2. [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. Need rules for 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.
3. [CDL*] Code List rules.
4. Regarding [DOC2], can content component restrictions be used to
limit the allowed values of a code list? If not, where would
they be used?
-----
Other
-----
1. [STD1] For every ccts:CCT whose supplementary components map
directly onto the properties of a built-in xsd:Datatype,
the ccts:CCT MUST be defined as a named xsd:simpleType
in the ccts:CCT schema module.
AIs:
TC-> + 1.01: Need way to say which cct should use this rule. Otherwise
it is up to tools person to figure out which do and which
don't map, but that is really not a tools issue.
Should be noted somewhere?
Mark, 20041106:
Adopting CEFACT CCT and UDT resolves this issue.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]