[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Summary of Issues and Actions Towards Draft-9
Summary Page
============
1. CoreComponentType Content Issues
2. New "xsd" Subdirectory Structure
3. Code List Stock Schema Issues
4. Schema Validation Issues
5. Schema Namespace/Version Issues
:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.
1. CoreComponentType Content Issues
===================================
Clarifications:
---------------
All the types defined, other than "GloballyUniqueIdentifierType",
are inherited from 0p70 done by Gunther. These included the
controversial
cct:DateType
cct:TimeTYpe
cct:PercentType
cct:NameType
cct:ElectronicAddressType
"GloballyUniqueIdentifierType" and its simpleType and element
definitions were added in after discussions that found the
need for such. It is needed in the abstract modeling sense,
and doing it in CCT.xsd was not a must. It could be implemented
in Reusable.xsd in the next round of draft, though we may
lose the stricter pattern restriction. That portion of
type restriction will then go into prose description and
implementation will go up into the application's post-schema
validation instance (PSVI) space.
Tim or Stephen, are you able to include the definition of
"GloballyUniqueIdentifier" ABIE in Reusable.xls please?
For that matter, what about Date, Time, Percent, Name
and ElectronicAddress? The suggestion to submit these
for CCT couldn't go forward as Bill explained that they're
not in current CCT yet. So until they are, we probably
can't put them in CCT and claim as such. I think that
appears to be the state of affair right now.
Draft-9 Changes:
----------------
- GloballyUniqueIdentifer to be defined as ABIE in Reusable.
- "cct:GloballyUniqueIdentifierType" (and associated stuff)
to be removed from CCT.xsd
- "cct:DateType", "cct:TimeType", "cct:PercentType",
"cct:NameType", "cct:ElectronicAddressType" may be removed,
depending on further discussion (probably on Oct 07 LC call).
2. New "xsd" Subdirectory Structure
===================================
Clarifications:
---------------
A new subdirectory structure under the "xsd/" main directory
will be created. This improves the readability and
manageability of the "xsd/" directory, and facilitates
codelists management (see codelist stock schema issue
section below).
Draft-9 Changes:
----------------
The structure will look like:
xsd/
codelist/
etc/
UBL-CodeListCatalogue.xml
placebo/
UBL-CodeList-*-Placebo-*.xsd
standard/
UBL-CodeList-*-Standard-*.xsd
stock/
UBL-CodeList-*-Stock-*.xsd
use/
UBL-CodeList-*-Use-*.xsd
common/
UBL-CoreComponentParameters.xsd
UBL-CoreComponentTypes.xsd
UBL-Reusable.xsd
maindoc/
UBL-DespatchAdvice.xsd
UBL-Invoice.xsd
UBL-Order.xsd
UBL-OrderCancellation.xsd
UBL-OrderChange.xsd
UBL-OrderResponse.xsd
UBL-OrderResponseSimple.xsd
UBL-ReceiptAdvice.xsd
3. Code List Stock Schema Issues:
=================================
Clarifications:
---------------
Recent discussions on codelist implementation for
externally defined codelists might have had implications
on when and how they are stored into the final 1.0
package.
With the directory structure change above, the discussions
could go on but dettached from packaging. This is because
end-users could eventually download the final, legal, proper
UBL stock codelist for, say Country Code, and store them
into the "xsd/codelist/stock/" subdir. When in use, end-user
just copies them into the "use/" subdir and renames them from
*-Stock-*.xsd to *-Use-*.xsd.
For packaging 1.0, packaging team just implements within
the "use/" directory generic *-Placebo-* schemas so that
the document schemas can validate OOTB.
Draft-9 Changes:
----------------
- Schemas within the "use/" subdir will be the exact contents
of those corresponding schemas in "placebo/" subdir.
- The "stock/" subdir will be empty. But the subdir will be
created to let end-users place stock schemas.
4. Schema Validation Issues:
============================
Clarifications:
---------------
Due to the subdir changes, <import> locations need to be
modified accordingly. Relative paths have been used so
it doesn't affect where the end-user stored the final
top-level "xsd/" directory.
Schema loaders (and validators) are expected to be able to
load the schemas at different path-points correctly.
For instance, a loading of Reusable.xsd due to <import>
statement from loading "maindoc/DespatchAdvice.xsd" should
resolve in exactly the same way as if Reusable.xsd has
been loaded directly from "common/".
This is similar to relocating conventional HTML pages.
The expected loading behavior above is not unreasonable.
As schema applications are currently being developed,
it is not yet clear how many are capable in doing these
relative loadings. If we encounter applications which
break because they are unable to load the paths pointing
to the new subdirectory structure properly, we might have
to require the application to upgrade in favor of keeping
the benefits in logical and organisational clarity the
subdirectory structure brings.
However, with Stephen Green's help, the new structure and
relatively-pathnamed schemas have been tried out on
XML Spy v5 and have yielded complete and successful outcome.
Draft-9 Changes:
----------------
- <import> schemaLocation values are different from
previous drafts when the schemas were expected to
be stored in the same directory. Now, relative paths
are used.
5. Schema Namespace/Version Issues:
===================================
Clarifications:
---------------
Currently, namespace have the form
UBLPrefix + ":" + SchemaName + ":" FinalVersion + ":" + WorkingVersion
an example of which is:
urn:oasis:names:tc:ubl:CoreComponentParameters:1.0:1.0-alpha
The working version will be bumped up each time we progress
towards the final version, whenupon the final version value
itself will be left duplicated in the namespace.
So we will drop the current's FinalVersion portion and
rely on the changes of WorkingVersion towards FinalVersion.
Draft-9 Changes:
----------------
- All schemas will use namespace value of the form:
UBLPrefix + ":" + SchemaName + ":" + WorkingVersion
an example of which is:
urn:oasis:names:tc:ubl:CoreComponentParameters:1.0-alpha
The final UBL 1.0 release will then have the namespace with
an example of the form:
urn:oasis:names:tc:ubl:CoreComponentParameters:1.0
:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.
Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]