On Jul 23, 2010, at 9:44 AM, Justin Edelson wrote:

> On 7/23/10 8:00 AM, Tony Giaccone wrote:
>> Yeah, you know.. 
>> 
>> I read that entry, and I certainly am in no position to comment on the cost 
>> of SNS in the repository. 
>> 
>> What I can say, is that if you are going to model real world data, and by 
>> data, I don't mean at the document level, but at a level of some detail, 
>> then lists, arrays of items of  the same type, are rampant and that is a 
>> data structure that has to be accommodated.
> But items of the same type do not need to have the same nam
> 
>> 
>> It's easy to say in the abstract, to use some identifying  title as the name 
>> of your node, as was done in the blog example, but... look at my example.
>> 
>> There's no "name" for a line item, that you can use like you would a blog 
>> posting. 
> What's strange about this statement to me is that the line items in your
> original post very obviously DID have names. You just called them id:
> <lineItem id=1>

I guess I'm distinguishing between numbers and names. Yes, a name can be a 
number, but I tend to think of names as being alphanumeric. 

Also I read somewhere, and I can't find the reference now, that one shouldn't 
use Numbers as node "names". 

My concern is more that I'm looking for some guidance and there's a lot of 
information out there from a variety of sources, and it's helpful for someone 
ignorant, like me, to understand the why as well as the rule.   I need to build 
my own mental model of how to build a document model. 


> 
> Alex is correct that this isn't a very user-friendly name, but I'm not
> sure how much that matters *in this particular context*.
> 
>> 
>> Line items have limited data and they have exactly the same structure, and 
>> they have data that's of the same types. 
>> 
>> So my question is, am I modeling at the wrong level of abstraction? Should I 
>> have one node that describes the whole order? If so how do I handle line 
>> items in that entry?
> I think you're heading in the right direction - one node containing the
> first-level properties of the order and then an ordered list of child
> nodes for the line items. As I said, I suggest using an intermediate
> node between the order node and the line items.

I'm right with you, your posting made total sense to me, but then Bertrand 
wrote about not using SNS, and that caused me no end of cognitive dissonance.  
What are arrays of objects? They are typically objects of the same type and 
would be modeled, I assume as SNS.  Now if you want to dodge that bullet by 
saying, Well they have names that are the ordinal number of the element in the 
array, ok.. I can live with that, but it feels like a hack, and not really the 
right way to structure that.

If we are modeling a document and there are a list of  paragraphs, aren't the 
paragraphs SNS (<p>)?

It seems we're playing fast and lose with the differences between a nodes name, 
it's "type" and it's ordinal position.  Now maybe that's the nature of mucking 
with nt:unstructured nodes, I don't know. But I'm trying to wrap my hands 
around how this all works. 

> 
>> 
>> If the solution isn't SNS then what is it?
> DNS (different named siblings) :)

Yes, well that's fine.. :-)


> 
> HTH,
> Justin
>> 
>> 
>> 
>> Tony
>> 
>> On Jul 23, 2010, at 4:12 AM, Bertrand Delacretaz wrote:
>> 
>>> On Thu, Jul 22, 2010 at 9:44 PM, Justin Edelson <[email protected]> 
>>> wrote:
>>>> On 7/22/10 3:17 PM, Tony Giaccone wrote:
>>>>> ...The problem I'm having is that I don't want to give each line item a 
>>>>> unique name.
>>>>> Does a node have to have a unique name?...
>>>> Theoretically, no, each node does not need a unique name if you use same
>>>> name siblings....
>>> 
>>> Note that SNS are a bad idea for a variety of reasons, see rule #4 at
>>> http://wiki.apache.org/jackrabbit/DavidsModel
>>> 
>>> -Bertrand
>> 
> 

Reply via email to