Profile

> > What it MUST include however, is the forest model. The reason for > this is that the existing profile gives: Several weeks into this discussion, I still have not seen a single concrete use case that warrants this. > As the profile stands now, with a choice of general DAG and > concrete URI, ...

> > As I said in the first msg after the call, the only drawback I see > to this is that the ancestor information and the URI form might be > inconsistent with each other. As I also said, there are lots of > other ways that the Request Context can contain inconsistent > information, which we do not ...

ZThese replies contain no explanation as to their basis. You are simply making opposite assertions and not backing it up with any basis. For example: "DAG describes what to apply precisely." Unfortunately, we have been over this so many time that I can not just keep repeating the arguments. But I will ...

On Mar 4, 2009, at 10:52 AM, Rich.Levinson wrote: The reason I am concerned about this issue is that from a security perspective, it makes little sense to me to force commonly understood hierarchies, such as organization charts, geographic breakdowns of organization operations, whether within a building ...

That is a very good list of suggestions, Erik. > > - Remove all the new definitions of "polyarchy", etc. They are not > needed. Use only the term "DAG". > > - Define a hierarchy as a DAG, where the nodes correspond to > resources and the edges correspond to child-parent relationships. > > - Define ...