On 2/8/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > 5. Lenya 1.2 defined "Usecase" as "special process separate from the
> > primary process".  General Usage defines "Usecase" as "Real world
> > actions required to complete a task".  There was a major discrepancy.
> > Lenya 1.4 changed the term to "Module".
> That's not quite correct, usecases and modules are not the same.
> A usecase is an action controlled by parameters, it can use forms
> etc. for user interaction. A module is a container for related
> resources. Modules can provide usecases.

1.2's Usecase provide a new entry point to a Publication.
1.4's Modules provide a new entry point to a Publication, plus a
directory and file naming scheme for the new functionality.

I used Usecases in 1.2 for adding most functionality that would not be
in the Authoring or Live Modules in 1.4.  It was cleaner than hacking
publication-sitemap.xmap all the time.  But I think weirdly.


> >   All graphics should be "Assets"
> I wouldn't introduce a common term for "all graphics". If it's an
> image, call it image, if it's a PDF, call it PDF ...

(I use "Image" for something graphical that is seen, and "Graphic" or
"Graphic File" for something that is created and manipulated.  My
brain is much too anal-ytical.  Most people use them interchangeably,
and prefer using Image for both of my definitions.)

I was not defining Asset as "all graphics".  I define "Asset" as any
content information that is not XML.  Images are one type of Asset.

> > Presentation configuration will be moved
> > inside Modules.  While none of the old definitions of "Resource" are
> > needed, the word is already used by Lenya, and should be used before
> > adding a new word.
> As I understood it, the term "resource" is rejected by most developers,
> because the meaning is too general. But I guess "resource" vs.
> "content item" will be a never-ending story unless we do a vote and
> all developers commit to the decision.

The General Usage definition of Resource is "something usable".  Lenya
1.2 defined "Resources" as "Anything usable that does not fit another
term."  With Modules getting the functional and configuration parts
out of the way, all that is left is Content.  The most usable units of
Content are Documents and Assets.  A generic term for both types of
data seems good for conversation and programming class naming. 
Obeying my Rules "Use an exiting word if one exists" and "Use one word
instead of two", "Resource" is a good choice.    If anyone finds a
better word (within the Rules), I will not be upset.


> > ===
> > On 2/7/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote:
> >> What both models of http://wiki.apache.org/lenya/GlossaryStructure have
> >> in common is that "content" is stored in a Publication. Now Andreas is
> >> using frequently the word "structure" in referring to the sitetree or
> >> like solprovider is calling it index of a publication. Seeing it from a
> >> different angle a sitetree or index or structure is nothing else then
> >> the typical table of content (toc) of a (text) book.
> > 1. "TableOfContent" is three words where we have been using one
> > ("Sitetree").  It also implies a single structure.
> > 2. "TOC" is not immediately recognizable by people outside the printed
> > paper industry.
> I agree to these points, but I'd replace "sitetree" with "structure"
> or "index".

"Sitetree" is defined in Lenya 1.2 as "XML maintaining the
relationships of Documents in a hierarchy."
"Structure" is not defined in Lenya yet.  General Usage defines
"structure" as "something composed of multiple parts, or their
arrangement", which fits how you have been using it.  "Sitetree" is
the better (more specific) choice when referring to the XML
representation of the arrangement of Content in a Publication.
"Index" is the accepted term in many related technologies (computer
databases) for "a data structure external to the primary data storage
used to organize it."  Some platforms use "View" to mean "the
resulting data when looking at data sorted and filtered by an Index",
but Cocoon redefined "View" to mean a "Breakpoint".

I like keeping structure as a generic term.  Content has structure,
but so does a Document, Publication, and even the Lenya Server.

> > 3. Andreas uses "Structure" to mean the one and only hierarchical
> > structure of information within a Publication.
> Not necessarily, I don't mind having multiple structures per publication,
> though the current API draft supports only a single one.
I am hoping to change that.

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to