[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)
Chin Chee-Kai wrote: > It seems that the design of namespace values by itself is already > not immutable over time with or without this discussion. > > The appending of version numbers to namespaces means namespace > values will change in time, which is not good and does not help > in migration phase from version changes. You seem to be implying that a namespace (for example, a namespace for <Order>) should not change from version to version. While I am aware that this is one possible position regarding namespaces, that is not the view of namespaces that has been adopted. The view that has been adopted is that when something changes in a schema, its version changes, and so does its namespace and its namespace name. Whether the namespace changes by virtue of changing the version-dependent part of the namespace name or by virtue of some arbitrary change in that name is not as important as the fact that it does change. In our case we have decided that it does change, and that change manifests itself as a mirror of the version. I am not sure I agree with you that this does not help in migration phase from one version to another. > > > > Best Regards, > Chin Chee-Kai > SoftML > Tel: +65-6820-2979 > Fax: +65-6743-7875 > Email: cheekai@SoftML.Net > http://SoftML.Net/ > > > On Sat, 28 Jun 2003, 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. >>> >>>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 >>> >>>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 >>> >>> > > -- 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]