OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


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


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



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