Re: [regrep-cc-review] Kickoff!

[Farrukh Najmi <farrukh.najmi@sun.com>]

Diego Ballvé wrote:

>>It would be good if someone can take a defense of 
>>(b) and see 
>>if our arguments for (a) have holes in them.
>>    
>>
>
>I have some points to be solved still. Not in favour of
>(b) but possible obstacles for (a)
>
>- DictionaryEntryName is composed of parts. Shall the parts
>be stored in the ExtrinsicObject, they probably will not be
>interanionalized. Not sure if they would need to anyway,
>but modellers here defined them in Finnish, not English.
>
I did not realize that at first.

If we need to keep the components of DisctionaryEntryName distinct then 
we should not map it to Name but to a Slot where each component can be a 
value. The name could show the concatenation of the values for convenience.

>
>- A RIM Slot can have n values, but each value has a maximum
>length. I've tweaked JAXR provider to keep values order, and
>it works in my case, but that is not according to standard.
>(Any plans to get RIM Slot values as an ordered collection?)
>
Just added to our TO DO list for spec work. This could be done as a fix 
for V3 (bug fixes on 2.5).

>
>- By keeping Slots' values order I'm able to store longer
>texts to a slot and, based on slot.type decide wether to
>handle it as many 'short' strings (1 per value), a 'long'
>string (catenate all) or as many 'long' strings (catenate
>all and tokinize).
>
Diego, since you are now a member of the TC it may be good if you could 
propose how we can formalize these improvements in Slot model. We will 
do what we can in V3 if TC agrees.

>
>- 0..* and 1..* properties are harder to handle if the
>possible values are not known beforehand. How to name the
>slot then??
>
>  
>
I am not sure what you meant here. An example that include how you 
handle it now and how ideally it should be handled would be great.

-- 
Farrukh