On 2/8/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > El mié, 08-02-2006 a las 13:12 -0500, [EMAIL PROTECTED] escribió: > > On 2/8/06, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > > > 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. > Yeah, for lenya ATM you may are right but see e.g. something like > forrest where this is not true. I will start very soon a forrest > compatible lenya pub where I will drop this focus.
It sounds like I should check out Forrest. From reading the Lenya MLs, it sounded like most of the Forrest project could become Lenya Modules. Is that correct? > Lenya never stated to be *just* a web CMS focusing on editing webpages > (html). That may is your assumption from knowing 1.2 but making lenya > forest compatible will give you a collection of new outputs out of the > box. Some already are available in lenya like OpenOffice and basic > OpenFormat support. The idea is to use lenya to manage any kind of > content not only webbased on. Good idea. It does not change the definitions of Page and Document. See below. > > 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. > > Here you see that some formats are referring to the response of a > request as document (be it the "pure XML definition" or not). Not only > RSS but as well e.g. open office, POD and pdf are referring to the > response of a request as a "Document". Even you can say "the html > document". I have never referred to an "HTML Document". HTML has Pages. XML has Documents. RSS and OOo are XML-based software, so they use "Documents". PDF and MSWord refer to "Word Processing Document", which is not necessarily XML, although both formats can be converted to XML. What is "POD"? > > > What is the relationship between document and pages? > > Documents are internal units of XML data. > see above, why limiting documents to xml? Because XML has "XML Documents", Lenya and Cocoon are XML-based, and that is how "Document" was defined for Lenya 1.2. How could Lenya change to work with non-XML data? I am not certain it is possible. Much of Lenya's functionality is the merging and filtering of data. There must be a common format for the data. XML is the current (and probably best) format. Let us pretend there is a Module that coverts an Image to XML. What could we do with it? Converting a PDF or MSWord DOC to XML produces something usable, but I doubt Lenya should do anything before they are converted to XML. Everything must be converted to XML, or treated as an uploadable/downloadable/unchangeable-within-Lenya Asset. > > 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. > Hmm, separation by purpose normally brings a different "type". Like in > forrest document-v20.dtd is for "normal" docs and faq-v12.dtd for faq > documents. I think the type determines the purpose. This was giving reasons to have more than one Document. You can have a FAQ about Lenya, and a FAQ about Forrest. I probably should have used "Subject" instead of "Purpose". > > 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. > I agree on type, but security is provided by the overall application > controller (lenya). The documents should be only linked in the security > component and not know about security itself. A Resource (Document, Asset, and even Code) should be able to configure its own security. Yes, security must be handled by the platform, but each Resource should be able to configure who can read it, who can edit it, and sometimes who can or is required to approve or publish it. Most of the time that list is inherited from the Parent or a default, but each Resource should be able to change it. An Image, such as the company logo, can be read by everybody, edited by the graphics designer, and approved/published by senior management. A Document, such as the draft of a financial report, may be seen by accounting and senior management, edited by accounting, must be approved by 2 senior managers, and published by the CFO. Workflow handles most of it, but Security verifies what is allowed. The janitor cannot read the financial report until publishing (Workflow) changes the security of the Document so everybody can read it. > > 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. > Coming back to the "printed paper industry" (the main user of a CMS!) a > paper is *one* piece of a document and not the other way around. The > above said *only* makes sense in html. You do not need navigation e.g. > in POD or PDF or .... Yes, most of my ideas are assuming HTML. Yes, in the print industry, Pages are sections of a Document. And in one of my posts, I suggested a Module that returns a section of a Document. Documents (as XML) are units of data. Pages are units of display. Whether a Page is built from zero, one, or more Documents depends on the requirements. Whether a Page uses the entire Document depends on the requirements. The "menu" and "rss" Modules use a very small portion of many Resources to create one Document. The "page" Module returns a section of a Document. The "live" Module aggregates them and returns an HTML Page. > The above re-written: > "When creating a content aggregation, Lenya can use different content > nuggets like introduction text, a list of products, navigation based on > the Publication, and other presentation information." Andreas and I have both said we do not care if the term is "ContentItem" or "Resource". Only you have commented on "ContentNugget". I really do not care, except... In one of today's posts, I implied that I do not want it named "Content" because I want the class to be usable for development Resources, such as CSS, XMAPs, XSLTs, and XSPs. The Security layer will be very important to restrict access to the developers. The Translation layer is easily disabled (just have only one Translation and set it as the default), but might be useful for CSS and sometimes XSLTs (different XSL used for LTR and RTL languages). The Revision layer would be useful for anything editable. (Would it be good to be able to rollback an XMAP?) > > 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.) > Well that is exactly what the forrest dispatcher does but for multiple > formats (<forrest:view type="css" hooksXpath="/"/> and <forrest:view > type="html" hooksXpath="/html/body">) > [Forrest code] I did not understand the Forrest code, but I will accept that Forrest applies similar functions to CSS as Lenya applies to XML. Lenya could merge CSS Elements from many Documents into one Document, and transform the CSS tag into proper format for HTML. I am not certain why that is important since every graphical web browser accepts multiple CSS inputs. > > > 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. > > wow, all the above said about NavigationModule is for me just a contract > of the dispatcher and do not have to be in a module. "Dispatcher" is a Forrest term, not a Lenya term. In Lenya 1.2, the Navigation framework handles most multiple (entire Publication) Resource inputs to create menus and such. In Lenya 1.4, the Navigation framework should be moved to Modules. As I said earlier in this post, I thought much of Forrest could be Lenya Modules. What does the "Dispatcher" do, and how will it add value to Lenya? > > 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. > IMO you are limiting the naming to certain formats and resulting > processes which IMO is not suitable for a multi-format environment/CMS. > Further I do not see the need nor the benefits and would like to see > consisting naming for users and devs. > "Lenya never stated to be *just* a web CMS focusing on editing webpages > (html)." ;-) I have not noticed the Lenya front-end client. There have been mentions of using WebDAV clients with Lenya (usually because there were problems.) I am uncertain how my suggested terminology limits Lenya when used in a "multi-format environment". Information in any XML format (XHTML, SVG) is called a "Document", can be edited, and can be manipulated by XSL. Information not in XML format is called an "Asset", is not editable within Lenya, and can be uploaded and downloaded. Both are "Resources" and have Security, Translations, and Revisions: the primary functions of a CMS. Accepting that Lenya will be used to store content in many formats, how do you propose to add value to non-XML data besides storage and retrieval? A customer of mine uses Lenya to store PDFs. They complain accessing the information in those PDFs loses the Website's navigation, they cannot provide links to anchors in the PDFs, and (because of the really limited software they use to create PDFs) they cannot add links in the PDFs. We could provide a PDF editor within Lenya that would solve most of the issues, but there is no good reason why the information in those PDFs is not stored in Lenya's standard "xhtml" Documents. How will Lenya add value to MSWord DOC files? MSExcel XLS files? MSPowerPoint PPTs? GIFs? JPEGs? PNGs? MPEGs? AVIs? WMVs? Can any of these be edited in Lenya? Or are they just Assets, with upload, download, Security, Translations, and Revisions? solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
