[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-cmsc] SC news
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]