For the NDR CheckList [R 115] Header, I'd like to propose
the following clarification. Due to time constraints, I'd
like to request that differing opinions from any body be
posted soonest. If there's no response, no consensus or
no outcome from this discussion, then it may be necessary
to remove this rule from NDR's Checklist because it cannot
be implemented in a agreed manner.
A. [Clarification] "metadata" should be clarified as "metadata
in the document instance space".
B. [Clarification] "proceeds" should be "precedes", otherwise
"Head" or "Header" wouldn't mean much.
C. [Change] Header + Body normally go together in a number of
standards specification. SOAP uses "Header"; ICE uses
"header". There're no clashes due to XML's forward-wisdom
in introducing namespaces. There's no real need to avoid
using the name "Header" as long as it is namespace-qualified
with, say, "ccts:Header". As "Header" and "Head" are
slightly different in meanings, and "Header" is in more
common usage, we should stick to using "Header" (with
namespace qualification).
D. [Change] In the interest of not defining too many namespaces
within UBL, that this generic header be named "ccts:Header",
with prefix "ccts" taking the namespace of CoreComponentParameters.
E. [Change] We should define only 1 generic header that has
some common sub-elements (see below as well) that apply
across all (or most) business documents and a miscellaneous
sub-element that allows UBL processors to store arbitrary
instance meta-information. The schema structure
for this 1 generic header will then be sufficiently general
to cater to all business documents, rather than having
one header for each business document.
Advantages:
+ Need only to focus on 1 header schema instead of
1 per business document.
+ Scalable: Same header applies to many business documents
+ Presence of a "well-known" element: This allows UBL
processors to at least be able to make assumptions that
this same element is always present regardless of any
incoming UBL document.
+ More amenable with contextualization, as it stays invariant
(different namespace from the biz-doc's namespace), allowing
UBL processors to at least be able to assume the presence of
a "well-known" element that contains meta-data that it needs
to proceed further with post-contextualization work.
This same header, being invariant, could be useful to store
bridging information for pre- and post- contextualization
processing for certain types of systems.
+ A miscellaneous child element permitting any type of
sub-elements provides flexible room for UBL processing
systems to introduce any suitable meta information applicable
on-site, rather than determined up-front (if that is at all
possible).
F. [Change] This generic header, "ccts:Header", shall take the
following sub-elements (shown as an instantiated example for
simplicity of illustration):
<ccts:Header>
<ccts:Version>0.80</ccts:Version>
<ccts:DocumentType>Order</ccts:DocumentType>
<ccts:DocumentID>
55964AFD-2556-4FE6-8248-445DFCAF8B1E
</ccts:DocumentID>
<!-- Other header elements to be determined and added
in v1.0 or subsequently decided by UBL TC -->
<ccts:ApplicationInformation>
<!-- Any element or content that the UBL processing
system deems necessary to store in this
document instance -->
</ccts:ApplicationInformation>
</ccts:Header>
Note: UBL namespace values are computed from version
and document type, but it is not a good thing to have
to expect UBL processors reverse-analyse an unknown
namespace from an yet-unknown incoming document. Thus,
the 2 important pieces of metadata - version and document
type - need to be stored explcitly.
The above points presented to kickoff some discussion,
and hopefully some consensus can be reached soon.
Thanks.
Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/
On Fri, 27 Jun 2003, Lisa-Aeon wrote:
>>In the LCSC call today, we discussed the containership of the header. the
>>rule as it reads is very ambiguous. It does not go into what is contained
>>in that header container. Chee-Kai is looking for more information about
>>what is inside.
>>
>>The current rule R115 reads:
>>
>>"All documents shall have a container for metadata and which proceeds the
>>body of the document and is named "Head" _____________. (anything but
>>header)"
>>
>>This does not go into what goes inside. So, the discussion within LCSC was
>>how to distinquish what is what. We will be asked to discuss this on next
>>Tuesday's joint call with LCSC.
>>
>>So, please everybody give this some thought and continue this thread until
>>we have solid answers to give the LCSC group.
>>
>>Lisa
>>
>>
>>++++++++++++++++++++++++++++++++++++++++++++++++++++
>>Lisa Seaburg
>>AEON Consulting
>>Website: http://www.aeon-llc.com
>>Email: lseaburg@aeon-llc.com
>>Alternative Email: xcblgeek@yahoo.com
>>Phone: 662-562-7676
>>Cellphone: 662-501-7676
>>
>>"If you obey all the rules, you miss all the fun."
>> -Katharine Hepburn
>>++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>---
>>Outgoing mail is certified Virus Free.
>>Checked by AVG anti-virus system (http://www.grisoft.com).
>>Version: 6.0.474 / Virus Database: 272 - Release Date: 4/18/2003
>>