RE: [regrep] Proposal: RIM Slot enhancements

[Diego Ballvé <diego.ballve@republica.fi>]

<Diego>
1) The first point is to change the Slot.value attribute to an
"Ordered" Collection of LongName. A RIM Slot can have n values,
but currently the specification does not enforce the values'
order.
</Diego>

<Nikola> 
I am not sure about this. It seems to be quite restrictive. If the purpose
is [hint 2)] to enable chunking of long-long-... values than, as we've
discussed before, I'd rather try to find a generic solution that is not
specific only to slots (we've seen issues with RegistryObject.description as
well). Also, ordering of things might be a topic on its own and temporal
ordering should be looked at from that perspective.
<Nikola> 

Restrictive? Do you mean that it would be better if there were no
max lengths at all? Do you have anything in mind already (from
previous discussions)??

<Diego>
2) Once (1) is accepted, we could define some special values
for attribute slotType and extendend the semantics of Slot.
Based on the Slot.slotType, we could then decide wether to
handle Slot.values as:
- only 1 'short' string (values.size must be 1)
- many 'short' strings (1 per value)
- a 'long' string (catenate all values)
- many 'long' strings (catenate all values and tokenize)
</Diego>


<Nikola> 
We should not think about Slot Types, Names and their Values as just
(collection of) strings even though they are expressed as such -> strings
can hold all sorts of things and we should not define at the spec level what
kind of things. I can envision that some specific efforts, like CCTS -> RIM
mapping, would use Slot.slotType/.name/.value(s) in some prescribed way(s),
but that should only apply to that specific effort.
</Nikola>

Ok, I was too tied to representation here, that was not the point.
You can even store binary in a Slot if you encode it, say, with base64.
The point is you cannot say a Slot can hold all sorts of things if at
the same time you say that the thing should fit in a string with 128 (?)
characters.

I agree that specific efforts will use slots differently and thus
define their ways to do it, and whatever these ways are they should
not affect how "basic" RIM is handled. Now if you see these ways
as patterns you can save time on thinking and reuse ideas across
efforts.

Diego