You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/05/26 08:27:59 UTC

Leaves and branches (was: Re: [1.4] DocumentManager.add())

Hi Lenya devs,

we're talking about "leaves" and "branches", but I have to admit
that I don't know exactly what these terms mean.

IIUC leaf/branch are used to distinguish node types in a tree-like
structure. In Lenya, there's no general concept of a tree, apart
from the tree implied by the URL space:


/foo/bar/index
/foo/baz/index
/foo/baz/xyz

           foo
          /   \
        bar    baz
        /      /  \
     index  index xyz


If we're talking about this tree, then it would be possible to introduce
the leaf/branch concept in the framework. But that leads to a restriction:

It is not possible to prevent the creation of nodes which are not
URL tree children of the current document.

Assume you have a URI structure like this:

/news
/news_page1
/news_page2
/tv
/tv_page1
/tv_page2
/...

where /news is the main page of a section and other pages are
separated using the underscore character. In this case it would not
be possible to restrict creation using the URL space tree.

If we use the leaf/branch concept for the URL space tree, IMO we have
to be aware that this implies a restriction.

-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: Leaves and branches

Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:

> At the moment we don't have this repository abstraction, we just
> operate on sources.

exactly, and it would be a mistake to expose storage details in the API. 
who cares if nodes are stored as folders or attributes internally?

> But anyway, IMO the leaf/branch issue on the repository side is not
> related to the Creator interface. The Creator is related to the site
> structure, not to the internal representation of the files. The user
> doesn't care whether a document is stored as a child file/node of
> another document, she cares whether it is a child in the site structure
> (which are entirely different things in the Lenya core, though they can
> be related in specific publications).

+1 and even on the site, it is silly to restrict it, because that means 
if you change your mind and want to add child nodes to a leaf node, you 
have to start over. which is exactly why we have never used it.

> Imagine you have a tree-like site structure and a flat-file storage.
> The parent-child relations are managed by the SiteManager component.
> So it doesn't make sense to use a leaf/branch concept on the file system
> (storage), but the SiteManager has to know the difference between a leaf
> and a branch. At the moment, there is no such concept. If we introduce
> it, we're restricted to trees again (what about topic maps etc.?).

-1 for introducing it

> But if someone uses the underscore instead of the slash to separate
> parents from children, the Creator has no chance to interfere:
> 
>   /foo_leaf
>   /foo_leaf_bar <- allowed by the creator

it is wrong to infer structure from the URI space. URI are opaque:

http://www.w3.org/2001/tag/2002/0508-intro#URI-meaning

> If you want to create a section that can't have children (for instance
> a "contact" section), you can't use the URL space tree for this
> purpose.

why would you restrict that? sounds like a solution looking for a 
problem. an API that tries to second-guess users is destined to fail.

> This means that the above contract is a restriction - it restricts
> the parent-child relation to the slash-separated URL space. I just
> wanted to illustrate that such a contract is very specific, even
> if it does look general on the first glance.

> IMO the most reasonable way to use the leaf/branch concept is to add
> it to the SiteManager, which would mean a restriction tree structures.

-1 based on the grounds above

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: Leaves and branches

Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
> 
>> Hi Lenya devs,
>>
>> we're talking about "leaves" and "branches", but I have to admit
>> that I don't know exactly what these terms mean.
> 
> 
> 
> well, one could also use the terms
> 
> files/folders (resp. directories)
> 
> or
> 
> resources/collections (WebDAV)
> 
> or
> 
> jcr-properties/jcr-nodes (JCR)

Hmmm, that would mean to introduce a general concept that could
be applied to various specific implementations. This requires a
general abstraction layer above these implementations which contains
the notion of leaves and branches:


           +---------+
           | Creator |
           +---------+
                |
     +-----------------------+
     | tree-based repository |
     +-----------------------+
         |        |        |
  +-------+    +-----+  +--------+
  | Files |    | JCR |  | WebDAV |
  +-------+    +-----+  +--------+

At the moment we don't have this repository abstraction, we just
operate on sources.

BTW, IIUC WebDAV is rather an interface to provide a client-side
abstraction, whereas JCR and Files are an internal storage mechanism.
I could imagine something like

      +-----------+
      | Client    |
      +-----------+
            |
            v
      +-----------+
      | WebDAV    |
      +-----------+
            |
            | - some arbitrary mapping
            v
      +------------------------------+
      | repository (JCR, Files, ...) |
      +------------------------------+

Or did I get this entirely wrong?


But anyway, IMO the leaf/branch issue on the repository side is not
related to the Creator interface. The Creator is related to the site
structure, not to the internal representation of the files. The user
doesn't care whether a document is stored as a child file/node of
another document, she cares whether it is a child in the site structure
(which are entirely different things in the Lenya core, though they can
be related in specific publications).

Imagine you have a tree-like site structure and a flat-file storage.
The parent-child relations are managed by the SiteManager component.
So it doesn't make sense to use a leaf/branch concept on the file system
(storage), but the SiteManager has to know the difference between a leaf
and a branch. At the moment, there is no such concept. If we introduce
it, we're restricted to trees again (what about topic maps etc.?).



>> IIUC leaf/branch are used to distinguish node types in a tree-like
>> structure. In Lenya, there's no general concept of a tree, apart
>> from the tree implied by the URL space:
>>
>>
>> /foo/bar/index
>> /foo/baz/index
>> /foo/baz/xyz
>>
>>           foo
>>          /   \
>>        bar    baz
>>        /      /  \
>>     index  index xyz
>>
>>
>> If we're talking about this tree, then it would be possible to introduce
>> the leaf/branch concept in the framework. But that leads to a 
>> restriction:
>>
>> It is not possible to prevent the creation of nodes which are not
>> URL tree children of the current document.
>>
>> Assume you have a URI structure like this:
>>
>> /news
>> /news_page1
>> /news_page2
>> /tv
>> /tv_page1
>> /tv_page2
>> /...
>>
>> where /news is the main page of a section and other pages are
>> separated using the underscore character. In this case it would not
>> be possible to restrict creation using the URL space tree.
> 
> 
> 
> I don't really understand what the restriction is resp. what cannot
> be restricted. Can you give another example?

OK, I'll try :)

Lets assume that Lenya states the following contract:

"A tree is formed by the URL space. A child node is separated from
the parent node by a slash (/). A leaf node may have no children."

This means that the Creator can avoid the following:

   /foo/leaf
   /foo/leaf/bar  <- not allowed! error message

But if someone uses the underscore instead of the slash to separate
parents from children, the Creator has no chance to interfere:

   /foo_leaf
   /foo_leaf_bar <- allowed by the creator

----

Another example:
Let's assume the SiteManager has a certain knowledge about document
relations which is derived from meta data. If a document is created,
the user adds a meta data term containing the section. For instance

   /news
   /msg2005-05-14-005     <- meta: section="news"
   /tv
   /msg2005-05-15-302     <- meta: section="tv"

There is a inherent tree structure which is known by the SiteManager
(for instance the SiteManager will not allow to delete the "news"
node as long as the "msg2005-05-14-005" exists).

If you want to create a section that can't have children (for instance
a "contact" section), you can't use the URL space tree for this
purpose.

----

This means that the above contract is a restriction - it restricts
the parent-child relation to the slash-separated URL space. I just
wanted to illustrate that such a contract is very specific, even
if it does look general on the first glance.

IMO the most reasonable way to use the leaf/branch concept is to add
it to the SiteManager, which would mean a restriction tree structures.

-- Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: Leaves and branches

Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:

> Hi Lenya devs,
>
> we're talking about "leaves" and "branches", but I have to admit
> that I don't know exactly what these terms mean.


well, one could also use the terms

files/folders (resp. directories)

or

resources/collections (WebDAV)

or

jcr-properties/jcr-nodes (JCR)

>
> IIUC leaf/branch are used to distinguish node types in a tree-like
> structure. In Lenya, there's no general concept of a tree, apart
> from the tree implied by the URL space:
>
>
> /foo/bar/index
> /foo/baz/index
> /foo/baz/xyz
>
>           foo
>          /   \
>        bar    baz
>        /      /  \
>     index  index xyz
>
>
> If we're talking about this tree, then it would be possible to introduce
> the leaf/branch concept in the framework. But that leads to a 
> restriction:
>
> It is not possible to prevent the creation of nodes which are not
> URL tree children of the current document.
>
> Assume you have a URI structure like this:
>
> /news
> /news_page1
> /news_page2
> /tv
> /tv_page1
> /tv_page2
> /...
>
> where /news is the main page of a section and other pages are
> separated using the underscore character. In this case it would not
> be possible to restrict creation using the URL space tree.


I don't really understand what the restriction is resp. what cannot
be restricted. Can you give another example?

Michi

>
>
> If we use the leaf/branch concept for the URL space tree, IMO we have
> to be aware that this implies a restriction.
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>


-- 
Michael Wechner
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner@wyona.com                        michi@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org