Re: [ubl-ndrsc] Containers: Headers

[Chin Chee-Kai <cheekai@softml.net>]

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
>>