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


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]