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: <DocumentInstance> proposal for versioning within instances


There was some talk about having version attribute in the
instance space to ensure instances carry version metadata around.
This is good, but we should not go in haste to add an
attribute "version" as in (by way of example again):

  <Invoice version="1.0">
    ...
  </Invoice>


It is foreseeable that  many more useful metadata for instance 
documents may be needed, either by way of UBL document design, 
or by application needs (just like <xsd:appinfo />)    and if 
we go by attribute now, we may eventually bloat the root element 
to such large chunk that reminds us of the earlier <ccts: >
attribute-based parameters in 0p70.

If we apply a generic holder such as <ccts:DocumentInstance>
defined (by way of example) as follows:

  <in:Invoice>
    <ccts:DocumentInstance>
      <ccts:Version>1.0</ccts:Version>
      <!-- Following are examples of other metadata -->
      <ccts:CreationDate>2003-10-01</ccts:CreationDate>
      <ccts:LastModificationDate>2003-10-03</ccts:LastModificationDate>
      <ccts:CreationApplication>UBLix v1.0</ccts:CreationApplication>
      <ccts:DocumentAuthor>Data Entry Personnel</ccts:DocumentAuthor>
      <ccts:ApplicationInformation>
        <!-- 
          Placeholder for application's local use.
          The schema description for this element would be:

          <xsd:any namespace="##other" processContents="skip"
                   minOccurs="0" maxOccurs="unbounded" />
        -->
        ...
      </ccts:ApplicationInformation>        
    </ccts:DocumentInstance>
    ...
    ...
  </in:Invoice>


extending and reading the elements could be considerably 
easier.  For <ccts:ApplicationInformation> especially, 
special encoding or formatting requirements would also be
more easily stored as CDATA or CDSECT than as attribute strings.

The idea is, then, to instantiate one such <ccts:DocumentInstance>
as a required first item in each main document schema.

Comments?

PS: I suspect this may need some discussions, and may not go
    into 1.0 in time.



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]