On 2/8/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > El mié, 08-02-2006 a las 12:01 -0500, [EMAIL PROTECTED] escribió: > > On 2/8/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > > > El mié, 08-02-2006 a las 12:37 +0100, J. Wolfgang Kaltz escribió: > > > > Andreas Hartmann schrieb: > > > > That's why I favor explicitly having the word "content" in whatever > > > > terminology we use to describe pieces of content. Thus my proposal a > > > > while back (http://wiki.apache.org/lenya/ProposalContentModel), where > > > > "ContentItem" is a piece of content (or ContentNugget, or whatever), and > > > > a Document is a collection of such pieces. > > > Ok, for me the above site is awesome and I agree as well on content item > > > because item = nugget. Nugget is just shorter as "ContentItem", why not > > > "Item". ;-) The only thing still hurting me is the document. You say "a > > > Document is a collection of such pieces" so why not call it > > > "ContentCollection" or "collection"? > > That page tries to redefine Document as a Page, then gets really > > confused when Documents (Pages) can contain multiple Documents (units > > of Content). > > > > One more time: a "Document" is the internal term for "a unit of > > information formatted as XML". A "Page" is a "response to a request > > by a visitor formatted as HTML." Visitors never see "Documents". > > I think I should just leave it like this, but: > > page -> why that is only html?
Websites use HTML. It is the primary format for web browsing. Most pipelines finish with <map:serialize type="html">. It is so common the type="html" is not necessary because it is the default. I sometimes serialize as XML for testing, but I do not want visitors to see it. The "rss" Module would serialize as XML, but RSS uses "Feeds" containing "Channels" containing "Items", as well as referring to the response as a "Document" using the pure XML definition. > What is the relationship between document and pages? Documents are internal units of XML data. They are separated by purpose, type, and security. Purpose: one Document contains the list of Contributors, another how to install Lenya. Different purpose, different document. Type: Most documents are XHTML, basic word processed content. A "product" document contains different (and more rigid) fields. Different DTD, different document. Security: One document can be edited by any editor. "Product" Documents can only be edited by the inventory maintainer. Different security requirements, different document. When creating a Page, Lenya can aggregate introduction text from one Document, a list of products from other Documents, navigation based on the Publication, and other presentation information. A Document is a possible input for creating a Page. A Page can be created from many Resources, including Documents, Assets, and Modules. (I have a few "You cannot do that" Pages that are just HTML files piped to the visitor. Responding to the request does not use any Documents or special processing.) > Why "a unit of information formatted as XML" can contain other "units of > information formatted as XML" (documents can contain other documents, > or)? I am not certain where this line appeared, but - when a unit of information formatted as XML contains other units of information formatted as XML, the result is a unit of information formatted as XML. or phrase it: - when a Document contains other Documents, the result is a Document. For example, a NavigationModule would aggregate many Documents, filter the data, and serialize as XML. The Live Module handles the result from a NavigationModule just like a Document retrieved from the datastore. The aggregation of a Document from the datastore with the results of several NavigationModules creates a new Document. That is passed to a Transformer to create an XHTML Document, which is passed to a Serializer to create the HTML Page (which may not be valid XML and so should not be called a Document) which is returned to the visitor. For programming purposes, "Document" always refers to an "XML Document". Some are stored in Content. Others are created by Modules, and only exist in memory. But all can be handled with the same functions. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
