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: Re: [ubl-lcsc] ccts Annotation Structure (fwd)


Tim, if you're referring to forwarding to NDR list for
discussion as well, I think Lisa has already done so.


She's tied that in with NDR Checklist [R96] for discussion:

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


But I responded that this rule relates more to optimization
issues than schema design, and is likely to be too stringent to
be stated as a rule as developers and users will find their own
means of optimizing schema usages best fitted to themselves.

Lisa, come to think further, I think they appear to be two 
tracks of discussions, with [R96] suggesting keeping 2 copies
of same schemas (modulo documentation), and "ccts Annotation
Structure" referring to the contents within <xsd:documentation>.




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


On Sat, 28 Jun 2003, Tim McGrath wrote:

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




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