Burcham, Bill wrote:
> 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.
Ok, I hate doing this, but I must ask you to identify and make a clear
reference to "the rule below", perhaps even a quotation, because I can
see no rule below that indicates that namespaces may not be immutable
over time. I'm confused.
>
> 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:Eduardo.Gutentag@Sun.COM]
> 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" <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_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: eduardo.gutentag@Sun.COM
Web Technologies and Standards | Phone: +1 510 550 4616 x31442
Sun Microsystems Inc. |
W3C AC Rep / OASIS TAB Chair