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: Preliminary Notes on Code List Schema Implementation

These are quick preliminary notes I gathered through some initial
implementation of code list schemas and linking them into
the Reusable and Model documents.  These are notes more to
myself explaining some micro-decisions made up on the fly
just to get things done.  But I think it'd be useful to share
with the list just to check on those areas.

Code List Catalogue:
The filename will be labeled as (for 1.0-alpha release):


and stored in the same "sss" directory as other model spreadsheets.

Inside the file:
1. The Code List Catalogue sheet will be named as
"CodeListCatalogue" instead of current "Sheet1".

2. The column header descriptions will be flushed at Row 1
to be in line with how the other model spreadsheets are laid out.
Extra blank rows currently sitting above the column headers
should be removed.

3. The descriptions of the column headers should be a single-lined
description without containing newlines.  For instance, the
Namespace Prefix"  currently with a newline after "Documentary"
should be written as just "Documentary Namespace Prefix" and
rely on the cell to format the presentation to break into 
2 or more lines as necessary.

4. The first 3 column header descriptions will be:

"Code List Namespace", "Documentary Namespace Prefix"
and "Code List Default".

5. Data rows (non-column-header) that have empty cells on
ANY one or more of the 3 columns indicated in (3) above will
be ignored.   With this mechanism, it is alright to leave
descriptive texts etc as per what is already there now.

Namespace Construction:
A. A given code list, whether internal or external, will be
uniquely and normatively identified via an assigned namespace
value that is stored under the "Code List Namespace" column.

B. The namespace value *may* be a function of the code list name,
version, agency, plus other anti-collision variables to make
two lists uniquely identified.  However, whether two given 
code lists are "alike" or not is a UBL-human decision.  
Complications (non-technical) could be from minor version updates,
or two completely exact enumerations but provided by two different
agencies.  This decision to disambiguate two code lists will be
implemented through assigning same or different namespace values 
to the code lists should they be deemed  the same or different 
code lists respectively.

C. Namespace values as stored in "Code List Namespace" now are
derived from *some* kind of dictionary entry name.  Those values,
when they do not contain any colon ":" character, will be 
internally imported into UBLish memory through another
derivation mechanism that makes them UBL-ish.  For example,
the "seen" namespace value for

	"DespatchAdvice. Type.. Code"

will be


However, if the value of "Code List Namespace" contains at
least a colon ":" character, then that value will be imported
into the schema generation tool as-is without further derivation.

D. In the next version of Code List Catalogue, the "Code List Namespace"
will be a normative value assigned by UBL to refer to any specific
code list whether or not it is internally or externally managed.

E. The "Documentary Namespace Prefix" will be still non-normative.
However, they are required to be unique across all rows in the
Code List Catalogue, and their contained namespace value must be
the same through out all UBL usages.

XSD Imports Within Reusable & Document Schemas:
(I). Due to *final* namespace value being the long form that may
be very cumbersome to serve as filenames, the mechanism used to
systematically derive the schema location file for each local
storage will be standardized as the proposed formula:

"UBL-" + prefix + "-" + UBLVersion [+ "-draft-" + draftNumber] + ".xsd"

The square brackets denote work-in-progress draft versions that
would be absent in final release.

So for instance, the  Shipment Priority Level Code with a prefix
defined as "spl" will have a mechanically derived filename of 


and its <xsd:import> will look like the following:

schemaLocation="UBL-spl-1.0-alpha-draft-1.xsd" /> 

(II).  Any prefixes referenced within Reusable or Document 
spreadsheets that are undefined or whose corresponding namespace
value cannot be found or is empty in the Code List Catalogue
will be flagged at the <xsd:import> block.  One example is:

<!--  ERROR: Empty or undefined namespace value for prefix reference

(III).  For Document spreadsheets, the ABIE's are tagged with
prefixes that are intended for instance-processing and have no
relationship with code lists.  However, the code list catalogue
mechanism is being "borrowed" to ferry the data into the schema.

It is true that the tool *can* tell or guess correctly that
"da", "in" etc should reference the namespace value of the
document itself (the targetNamespace).  However, this will
make the document ABIEs a special type of ABIE.  If Reusable
ABIEs use the same mechanism, they become treated differently.

Is this better/worse?  

As it is now, the code list generation logic is giving errors 

<!--  ERROR: Empty or undefined namespace value for prefix reference

As such, and also as a consistency checklist, I'd like to suggest
that the Code List Catalogue have entries for prefixes associated
with the 8 documents, such as "da" (Despatch Advice, but what's
the namespace value?), "in" (Invoice, but what's the namespace
value?), etc, plus one for CCT & core component parameters just
to be complete.    If this is less preferable, we might need to
consider adding (yet another!) column in the Reusable and Model
spreadsheets with heading "Documentary Instance Prefix"
and distinguish its use from that of "Documentary Namespace Prefix"
whose purpose will then be delgated solely for code list 

Any comments?  Please.

Type Reference Errors:

(i) For general type references that UBLish cannot find a
declaration for, an error comment block will be inserted into
the bottom chunk of global element definitions to indicate
the error.  The corresponding <element> that references an
unknown type will have its "type" attribute set to 
"unknown:[TypeRefName]Type"  where [TypeRefName] is replaced
with the local name of the originally intended type recorded
in the spreadsheet.   Thus, two examples found are:

<!--  ERROR: Unknown type reference "ReferenceType" required by element
<!--  ERROR: Unknown type reference "GuidType" required by element

In general, it would be necessary to ensure that there are 
no <!-- ERROR: ... -->  or <!-- WARNING: ... --> blocks
generated in order for the schema to work properly.

I'll send some interim results out soon.

Best Regards,
Chin Chee-Kai
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net

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