[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)
Did not Section 13 of "mod-nam-ver" make it into the rules? Lines 330-335 (version 08, Feb-26-2003): > In UBL, the major-version field of a namespace URI must be changed in a release that breaks compatibility with the > previous release of that namespace. If a change does not break compatibility then only the minor version need change. > Regardless, at a minimum any change to any schema module constituting the namespace necessitates some change to the > namespace URI. Said another way, once a namespace and its associated name are published by UBL they shall not change. Note that this bit "once a namespace and its associated name are published by UBL they shall not change" is emphasized (bold) in the source document. Actually, yeah, look at rule 48 in the NDR checklist: [R 48] A published namespace MUST never be changed. So you can't publish two versions of a namespace. If they're different, they must have different namespace names. -----Original Message----- From: Eduardo Gutentag [mailto:Eduardo.Gutentag@Sun.COM] Sent: Saturday, June 28, 2003 10:59 AM To: Burcham, Bill Cc: Lisa-Aeon; UBL-NDR Subject: Re: [ubl-ndrsc] Fw: [ubl-lcsc] ccts Annotation Structure (fwd) 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_wo >>r >>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_wo >>r >>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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]