Re: [ubl-cmsc] SC news

[Eduardo Gutentag <Eduardo.Gutentag@Sun.COM>]

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
> 

-- 
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 BoD