Re: [ubl-lcsc] ccts Annotation Structure (fwd)

[Tim McGrath <tmcgrath@portcomm.com.au>]

I personally see this as a more logical way to present the properties of 
the CCTS.  My memory on the origin of the structure for this is that is 
was an arbitary decision made at the beginning.  It is worth revisiting.  

However, I now realise that it should actually be an NDR rule. It may 
impact on alignment work with things like Garrett's OAG project.  So 
(sorry to do this to you again Chee-Kai), I suggest we also pass this on 
to NDR as well.  What we are asking the FPSC is whether this has 
significant impact (good or bad) on their work.  What we are asking NDR 
is whether this is/can/or should be an NDR rule.

Can you do that Chee-Kai?

Chin Chee-Kai wrote:

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

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160