Sorry, hit send too early on previous message.
From personal communication with David I understand that we have
basically two use cases for SNS: Importing content (e.g. XML) and
creating nodes where the name doesn't matter. For both cases the
stringent requirements of the spec. - which basically requires SNS to be
'array addressable' - are not necessary. That is, for these cases SNS
could be implemented on top of the MK (i.e. option b)) through name
mangling. In that case we need to clarify whether we can do this within
the spec. or whether we need to work on it.
Yes. Within the JCR API the index needs to be an int. One idea is to use a
global counter (global within the repository) as the index. So if you
import
<p>Hello</p><p>World</p>
it could end up as:
p[1356789000] = Hello
p[1356789002] = World
I don't know if this would be allowed according to the spec.
We were even thinking of using hash codes for the index. However, the
spec. does not allow any of this [1]:
"The indexing of same-name siblings begins at 1, not 0"
and further
"If a node with same-name siblings is removed, this decrements by one
the indices of all the siblings with indices greater than that of the
removed node. In other words, a removal compacts the array of same-name
siblings and causes the minimal re-numbering required to maintain the
original order but leave no gaps in the numbering."
Michael
[1] http://www.day.com/specs/jcr/2.0/22_Same-Name_Siblings.html
What about HierarchyEntry? This term is currently used in the SPI stack
for similar purposes.
HierarchyEntry instead of Node? To me it sounds a bit better than Tree,
but I would prefer something that contains the term Node.
Regards,
Thomas
