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: ccts Annotation Structure (fwd)


This was sent out on 24th Jun to LC.  I'm resending to FP and
cc-ing to LC again to request for comments on the proposed
change in structure for storing documentation information
in proper element than in attribute.

Please kindly take a look at the following and send in
your comments or it'll get implemented as proposed.

Thanks.


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


---------- Forwarded message ----------
Date: Tue, 24 Jun 2003 23:59:02 +0800 (SGT)
From: Chin Chee-Kai <cheekai@softml.net>
To: UBL LCSC <ubl-lcsc@lists.oasis-open.org>
Cc: Anne Hendry <anne.hendry@sun.com>
Subject: [ubl-lcsc] ccts Annotation Structure

Doing some review on the schemas myself, I have a growing
urge to reposition from 0p70's style of combining the documentation
into a single humongous element using attributes to hold data
into one that uses sub-elements to hold the documentation
information.

The suggested change goes something like this.  Using "AddressType"
as an example, the change is illustrated as follows:

Present style (0p80 alpha, inherited from 0p70):
================================================

<xsd:complexType name="AddressType">
  <xsd:annotation>
    <xsd:documentation>
      <ccts:ABIE dictionaryEntryName="Address. Details" definition="The
particulars that identify and locate the place where someone lives or is
situated, or where an organisation is situated." objectClass="Address"
propertyTerm="Details" representationTerm="Details" />
    </xsd:documentation>
  </xsd:annotation>
  .....
</xsd:complexType>



Proposed change:
================================================

<xsd:complexType name="AddressType">
  <xsd:annotation>
    <xsd:documentation>
      <ccts:BIE>
        <ccts:BIEType>ABIE</ccts:BIEType>
        <ccts:DictionaryEntryName>Address. Details</ccts:DictionaryEntryName>
        <ccts:Definition>
          The particulars that identify and locate the place where
          someone lives or is situated, or where an organisation is
          situated.
        </ccts:Definition>
        <ccts:ObjectClass>Address</ccts:ObjectClass>
        <ccts:PropertyTerm>Details</ccts:PropertyTerm>
        <ccts:RepresentationTerm>Details</ccts:RepresentationTerm>
      </ccts:BIE>
    </xsd:documentation>
  </xsd:annotation>
  .....
</xsd:complexType>



This proposed change will require some modification to the file
"CoreComponentParameters-0.8-draft-3.xsd".  Also, other tools
or applications that had depended on attribute values in 0p70
or 0p80 alpha will need to be modified to extract the data from
the new sub-elements.

In particular, the BIE type has been moved from the ccts namespace
to the data space contained within the proposed well-known sub-element
<ccts:BIEType>.  The parent <ccts:BIE> element will also be fixed
instead of 0p70's changing element name according to the BIE type.
The rationale is that BIE Type is as much a piece of meta data of
the complexType or element reference as other meta data such
as property term and representation term.  There appears to be
no clear reason why BIE type should have a special status of
being recorded in the ccts' namespace as an element name instead
of being stored as a data in the data space like other meta data.

The new <ccts:BIE> parent element will then be a fixed structure
applicable for all BIE documentation.  This means also that we
can reduce the various documentation types defined for each BIE
type (found in "CoreComponentParameters-0.8-draft-3.xsd") into
just 1 BIE documentation type applicable for all BIE types.

These changes, however, are not expected to be too substantial
in nature.  But the clarity and conformance to how types are
generally defined within UBL schemas will be the benefits gained
from this proposed change.

I'd like to find out what kind of response people have on this
suggestion, and whether I've missed out any important consequences
or effects the change will bring to anyone.

Comments?



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






You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php




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