Re: [regrep] Standards approval process

[Duane Nickull <dnickull@adobe.com>]

Ivan:

Please understand that I do not have all the answers, although I think I 
did answer many of them, it raised a lot of questions around scalability.

Answers inline:

BEDINI Ivan RD-BIZZ-CAE wrote:

>Please Duane, give us your mapping and if it will well formed we will
>stop this discussion immediately :-P
>  
>
The mapping is simple.  You store a [CC || ACC || BIE || ABIE] as a 
registry object. When you need it, you get it from the registry as a 
whole object.  Doing this also solves a second problem of a 
serialization format for interchange of CC's, BIUE's etc.  That is why I 
favour this.  It is also cleanly decoupled from any dependency upon a 
registry.

I have given an example of storing a BIE inline within a CC under the 
/representations element.  There can be multiple representation elements 
present given that there will be multiple BIE's for a CC, each used 
within a different set of contexts.  The context set is a keyed value 
than allows the correct BIE to be identified by the modeller based on 
his or her contexts.

The inline method will not scale well if there are lots of BIE's 
therefore, I would make a reference to the BIE and context and store 
them as separate registry objects.

Aggregates are expressed as a aggregated relationship for CC's (Not sure 
why composites are not used here but that is for CEFACT to decide.)

>sincerely give us the possibility to have a little doubt about how you
>deal CC in your mapping. in the solution that you provide we can't
>distinguish a BBIE from an ACC. all is CC for you.
>  
>
Not true.  It is very complicated but I used the same schema to define 
the metadata for all objects.  The differentiator is in the enumerated 
lists.

example

<Object type="[BIE || ABIE || CC | ACC]" /> allows you to declare what 
the thing is.

The properties map all the CC properties properly.

<Property name="foo" value="bar" />

>  
>
>>DN - that is what RSS is for.  We should not define a separate API just 
>>for CC related things.
>>
>>    
>>
>
>Why not ?!?
>  
>
The simple answer is that it is generally a bad practice to add features 
that are redundant with existing features without a compelling reason.  
I see no compelling reason why we should develop a new API when the one 
we have works perfectly for the purposes discussed.

>>DN -registry federation can do this.  We do not need to make another 
>>spec to do this.
>>
>>    
>>
>
>Please share your experience with us.
>  
>
DN - read the federation feature of the registry spec - it explains all.

Duane

-- 
***********
Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
Chair - OASIS eb SOA TC - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebsoa
***********