[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-cmsc] SC news
i agree with eduardo, the goal for 1.0 is to give syntactic rules for deriving a compliant UBL schema from a UBL 1.0 one. we are not able to say any more than that at this stage. i agree with dan, this is not terribly useful to anyone. but it is a placeholder until we can develop a true context (or rather, a customisation) methodology. we should just make sure we don't make over ambitious claims for what the CM 1.0 is doing. In fact, i believe that the primary objective of UBL, now that 1.0 is almost out the door, is to develop this methodology. And as Dan says, it must "...show how I would design the UBL schema from the start, now how I use those techniques with an existing schema that I want to modify in a modifiable way.". To customize means to alter something in order to make it fit somebodys requirements better. UBL was designed on an 80/20 principle - that 80 percent of the library would be useful to 80% of cases and that the 20% remainder would require a customization of the library. The corollary to this is that this 20% customization would be 80% of the complexity of using UBL. We are now seeing these complex issues emerge in several ways within the UBL Technical Committee: a. the Tools and Techniques SC are encountering issues with compliance or rather levels of compliance to suit customization. b. the Library Content SC is seeing how re-use and qualification of BIEs can customize them for other contexts. c. the Context Methodology SC are working on the issues of customizing W3C Schema (XSD) components for other contexts. d. The Naming and Design Rules SC are debating the implications of re-use of UBL (and CCTS) types. e. The Code List SC is designing a standard, stock and placebo code mechanism to support customization. f. The various newly formed Localizations SCs wish to customize UBL for their geopolitical context. I hope that over the next few weeks we can broaden the discussion in the group to address all these issues - but lets get 1.0 out first. PS As i mentioned at the plenary, I am trying to put together a 'unified theory' paper on customizing UBL, taking up ideas from Mike Adcock and others and fitting them in the perspective of the current CM work. Eduardo Gutentag wrote: > a) During the London meeting, 2003, the SC voted and decided not to > use redefine - the SC decided that the issue of namespaces was too > important to ignore. > > b) The issue of avoiding having to do the modifications again every > time there is a new release of UBL is one of the motivations behind > the planned phase 2. > > c) Even if it weren't, there would be no time to deal with it now. The > reality is that we're a few weeks away from v 1.0 and there simply is no > more time. The goal of the paper at this point is to show people mostly > what is ok to do... > > d) While it's true that ultimately people and orgs will have to figure > out how to do things in day to day settings, I believe (and this is my > personal opinion, as we've not passed this by the SC and no resolution > has been taken) it would be inappropriate for UBL to have a normative > method for how to do things. What may be appropriate for one company > or organization may not be appropriate for another trying to obtain > the same results. > > Regarding point (c) above, it could be argued that it's my fault that > we're so behind schedule that there is not much time for improvements > in the paper. And in great measure that would be a fair assessment. > On the other hand, you must agree surely that there hasn't been a > great deal of participation every time the paper was revved...So while > I do take responsibility and accept some blame, I don't think it's > 100% mine. > > Dan Vint wrote: > >> At 02:48 PM 3/8/2004 -0800, Eduardo Gutentag wrote: >> >>> - One of the reasons we need to meet is to finalize the version of >>> the document >>> that will go out with UBL v1.0 -- I'm attaching the latest version, >>> which is >>> a further development from the one that appeared in Beta; Arofan was >>> a busy >>> bee and sent me what is now Sections 5 and 6; I've edited them >>> lightly, and >>> would very much appreciate comments, in particular regarding, but >>> not limited to, >>> Code Lists. >> >> >> >> I'll go back to my comments form last Feb 2003. This document needs a >> more complete and working examples. The simple code of extension and >> restriction are nice, but they do not show the complete context of >> HOW it is done and made valid. They show how I would design the UBL >> schema from the start, now how I use those techniques with an >> existing schema that I want to modify in a modifiable way. >> >> Some assumptions I made but don't see here is that you would want a >> maintainable way of making the changes. For me this means having a >> separate file with your modifications that some how references in the >> UBL schemas and modifies them without editing the original files. So >> that as a new version of UBL is released you don't have to do a lot >> of rework to get your modifications back. >> >> I believe that this setup currently documented only allows you to >> make new types for use in new elements, it doesn't really allow you >> to adjust the existing definition UNLESS you go into the original >> definition and make the modification of the type. I also believe that >> the only way you can both extend and restrict the definition of an >> existing object is to use redefine. I'm willing to be convinced >> otherwise with some good examples of how you expect this to be >> implemented. >> >> From my work, I think you need to address the following scenarios, >> with complete details of the files involved, the use of namespaces, etc: >> - extending an existing UBL component - with UBL existing components >> and new components >> - restricting an existing UBL component >> - BOTH extending and restricting the same UBL component - with UBL >> existing components and new components >> - creating a new component that uses new components and reuses UBL >> types and components (a mixture of new things with existing UBL >> components) >> - extending codelists - I haven't seen what the latest design is >> here, but if you have an enumerated list of code values, you can't >> directly extend that list of values. >> >> - I think you also need to address the use of other schema features. >> I know that one document has a list of rules for the LCSC and what >> they can use, that list should be rationalized or reinforced with >> similar statements here for compatible vs non-compatible extensions. >> >> ..dan >> > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]