Would such a rule not conflict with the NDRSC rule that namespaces be
immutable over time? The rule below means to me that I can't count on a
particular namespace name reliably identifying a particular schema.
If we want to have optional documentation, then I think we should define it
externally from the get go. Anything that sits in the schemas as
annotations is there for good. Right?
-----Original Message-----
From: eduardo [mailto:]
Sent: Friday, June 27, 2003 7:37 PM
To: Lisa-Aeon
Cc: UBL-NDR
Subject: Re: [ubl-ndrsc] Fw: [ubl-lcsc] ccts Annotation Structure (fwd)
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.
>
Agreed. But has this decision made it yet to the NDR document? If it
has, it is
surprising that there is no rule associated with it...
>
>Lisa
>
>
>----- Original Message -----
>From: "Chin Chee-Kai" <>
>To: "UBL FPSC" <>
>Cc: "UBL LCSC" <>
>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:
>>http://SoftML.Net/
>>
>>
>>---------- Forwarded message ----------
>>Date: Tue, 24 Jun 2003 23:59:02 +0800 (SGT)
>>From: Chin Chee-Kai <>
>>To: UBL LCSC <>
>>Cc: Anne Hendry <>
>>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:
>>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_wor
>kgroup.php
>
>
>>
>>You may leave a Technical Committee at any time by visiting
>>
>>
>http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_wor
>kgroup.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_wo
>rkgroup.php
>
>
>
--
Eduardo Gutentag | e-mail:
Web Technologies and Standards | Phone: +1 510 550 4616 x31442
Sun Microsystems Inc. |
W3C AC Rep / OASIS TAB Chair
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgro
up.php
