OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [regrep] Proposal: RIM Slot enhancements

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'

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.

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)


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]