OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-cmsc message

[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]