On Wed, 2006-02-08 at 10:28 +0100, Andreas Hartmann wrote: > [EMAIL PROTECTED] wrote: > > [...] > > I mostly agree to that, but IMO changing an existing definition > is OK if it helps conforming to points 0 and 1. As I understand it, > the term "asset" is commonly used by other CMS (please correct me > if I'm wrong).
Here is a link about the term "asset" in CMS: http://www.contentmanager.net/magazine/article_200_media_asset_management.html Basically we're trying to unify documents and assets (from Lenya 1.2), right?. I could also imagine to call everything "document" instead of "asset". For me it's more natural to call a JPEG a "document", than to call an XHTML document an "asset". But it's a matter of personal preference... Josias > > > > 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. > > > > Lenya 1.4 has not defined "Resource" yet, > > but should relate to one or more of Lenya 1.2's definitions. Software > > plug-ins are being defined as "Modules". 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 ... > > > (Why allow static graphics? Let everything be editable, and > > improve security so the security granted by requiring file system > > access is unnecessary.) > > +1 > > > 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. > > > > 7. Lenya 1.2 defines "Publication" as "Content and related processing > > instructions" where "Content" is defined as "(XML) Documents and > > related Assets" where "Assets" is defined as "uploaded files". > > People keep suggesting using "Site", "Website", "Book", and other > > terms for this concept. General Usage defines "Publication" as "A > > specific issue of a public work including textual information". The > > output of a Lenya 1.2 Publication is close enough to the General Usage > > definition that very few people have been confused by the term. If it > > works, do not break it. > > +1 > > > > 8. "Resource" is better than "ContentItem" because it contains fewer words. > > Yes, but it bears a greater danger of clashes with other meanings of > the term (see above). My personal priority list is > > 1. asset > 2. resource > 3. content item > > but they're very close to each other. > > > > === > > 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". > > > > 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 think more > > flexibility would be easy. > > 4. I use "Index" to refer to an easily configurable internal data > > structure used to allow multiple "structures", both flat and > > hierarchical. Notice "internal". The only people aware of Indexes > > would be: > > - Programmers of core that implement the feature. > > - Developers of Modules that concern multiple Resources. ("Resource" > > being defined as Nodes within Content.) > > > > To clarify, the bulk of understanding "Index" falls to the programmers > > of core implementing the feature. The "live" Module is only concerned > > with one Resource, so the developer does not need to understand > > "Index". The "live" Module aggregates the result of the "menu" > > Module. The "menu" Module creates a list of multiple Resources, so > > configures a hierarchical Index. The developer of the "menu" Module > > only needs to understand that properly using XML to configure an > > "Index" allows using the following line to generate XML about multiple > > documents: > > <map:generate type="sitetree" index="myNewIndex"/> > > The SitetreeGenerator does the work; the developer looks at the > > resulting XML to see if the Index configuration is correct, then > > continues writing the Module (probably adding XSL transformations.) > > > > Indexes would also be used internally to translate between the ID (or > > URL) (/section/category/documentid) and the UNID (unique identifier of > > the Resource in the flat storage of Content) used to retrieve a > > Resource. Again, use of the Index is transparent to everybody except > > the core programmers implementing the feature. > > That sounds reasonable. > > -- Andreas > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
