Invert documents to get a different view

The author did change the way to look at the problem but did not really do an inversion!

The inversion would have been true if you would have started with the following framework:

instead the article started with this framework:

Of course, the "inverted" solution proposed makes answering the question of who are a person's ancestors easier!

But ask the inverted question of who are a person's descendants and you are back with looking at it from the wrong side!

And if you start looking at it with all the complexities of contemporary genealogies (multiple marriages, mixed families, ...) you would have a nightmare.

A better solution would be to look at it from a relationship point of view.

You can use relationship to either walk down or walk up the genealogy tree! (If you want to really confuse things, you could go both ways!)

In fact, you can extend the concept to non-familial relationships: friends, neighbours, contacts, etc.

Regards,
Steph

, Because it's an only correct approach to represent newer entity formed by the older entity. If for example I need to show an XML element "MyDetails" then I need to HAVE each of my details first before being able to show "MyDetails". At least I must have MYSELF first for my details to be available for getting typed tag by tag before it becomes a "MyDetails" element :) .
But genealogical tree is not a good example for XML though: it cannot represent my ancestors if one of the families has beenfounded by cousines (which is acceptable from the medical point of view). Different tags in this case will represent the same person. This is wrong. It drives to confusion.
So what to do?
I think we must figure out first what parameters are obligatory for some type of tag and what are not.
My opinion is that XML is initially for representing the data of flat structure, flat as the database row. We cannot represent sophisticated structure with it. There cannot be other XML tag than:

...

The example shown in article -

- represents mom and dad as a tags inside the person's tag. What is bad? Mom and dad are persons too, and that assumes existance grandma and grandpa tags inside them. It's notcorrect taking into account "cousine" factor. Moreover, I think that it's more correct to treat tag itself as a non-obligatory entity. If there is no specific tag then it means that this data is not specified and it doesn't corrupt the whole data structure. There cannot be case when father or mother is not specified somewhere in the middle of the tree: everyone has gotten mother and father, and this is not a complete tree in this case (tree has been splitted to different trees). That's why mother's and father's tag names must be specified as an obligatory parameters for each person's tag. Each person exists in the independent space, not inside any tag (we initially deserve the freedom!). To draw the tree we must draw first row of two persons - the family that we start from. Each next row will consist of the persons whose mother and father are in the previous row. And so one...
I think, the major difference between the article's example and my opinion is:
In case of the tree-view structure in XML, it is initially wrong to try to represent some entity inside the equal entity. There is no other way as to go down to the relational data structure concept and use the "pointer to parent" concept.

Thanks and regards.

methinks some posters are missing the point.

With the restrictions of article size, and taking in to account the title of the article, I think the message is achieved:
Sometimes it helps to break away from the conventional view and rethink the approach (dare I say) "outside of the box" (OUCH!).

I think Brian would agree that the example was simplistic and not meant to be a perfect resolution to a geneology coding problem. It is an example given to demonstrate another view to obtain a solution. On this level, it is appropriate, and of the correct difficulty, to demonstrate the point of the article. It would require a series of articles to present a "correct" solution to this problem.

Good job, Brian! Enjoyed the article, and it isa good reminder that the apparently straight forward approach is not always the only way to solve a problem.

Also, "good job" to the posters of the more finite solutions! Their comments pose interesting issues and questions about the hidden complexity of current geneology and how to code for them.