[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)
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: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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]