UBL Naming and Design Rules SC

 View Only

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

  • 1.  Re: [ubl-ndrsc] Fw: [ubl-lcsc] ccts Annotation Structure (fwd)

    Posted 06-30-2003 01:33
    Again, this two schemas per model rule is also something
    I feel is rather stringent to be stated as a rule, or that
    it is redundant.
    
    Developers and users will find their own most suitable form
    of optimizing for processing.  It shouldn't be a specified
    form of rule for such purposes.
    
    
    
    
    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:
    
    >>I am forwarding this from the FPSC and LCSC since this has to do with the
    >>embedded documentation in the schema.  The only rule we have in the
    >>checklist is R96, which states:
    >>
    >>"Two schemas shall be developed for each standard.  One schema shall be a
    >>run-time schema devoid of documentation. One schema shall be a fully
    >>annotated schema that employs XHTML for the annotations."
    >>
    >>There is not description of how it is to be used and can be intrepreted in
    >>many different ways.  Shall we join this discussion?
    >>
    >>I know that we voted on using xsd:documentation and not xsd:appinfo, for
    >>embedded documentation, I think there should be a rule saying this.
    >>
    >>Lisa
    >>
    >>
    >>----- Original Message -----
    >>From: "Chin Chee-Kai" <cheekai@softml.net>
    >>To: "UBL FPSC" <ubl-fpsc@lists.oasis-open.org>
    >>Cc: "UBL LCSC" <ubl-lcsc@lists.oasis-open.org>
    >>Sent: Friday, June 27, 2003 11:36 AM
    >>Subject: [ubl-lcsc] 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
    >>>
    >>>
    >>>
    >>> 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
    >>>
    >>
    >>
    >>---
    >>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
    >>
    >>
    >>You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php
    >>
    >>