On 2/7/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > Andreas Hartmann wrote: > > [EMAIL PROTECTED] wrote: > >> A Document is XML. An Asset is not XML. > > IMO we should use the term Asset for all content items, whether XML > > or not. I don't see the need for differentiating between XML and non-XML > > assets. > All content-related issues would be the responsibility of the AssetType > (formerly known as ResourceType / DocumentType). > For instance: > [Many examples of using Assets that are XML-based.]
I have a couple of thoughts/suggestions/objections. First, we need a superclass for objects placed in Content. This superclass contains identifiers, security information, and Translations (Nodes for different languages). Each Translation contains Revisions (Nodes for historical versions of each Translation). For the name of the superclass, we were discussing "ContentItem" or "Resource". Now you suggest "Asset" right after a discussion that wanted to define Assets as parts of a Document. Lenya 1.2 defines an Asset as an uploaded file. Why would we create a new definition of "Asset"? Are we trying to confuse everybody? Second, we need to separate XML and non-XML. Storage could use <resource type="XML"> and <resource type="non-XML">, but programming requires different class names for each. XML data can be aggregated, transformed, and serialized. "Document" is well-defined in XML and Lenya 1.2 as an XML Document. Why would we change that? Documents then have Types based on the DTD, (and possibly a PI or other XML.) In Lenya 1.2, the doctype parameter decided the Type. In 1.4, every Document should know its Type, but can be overridden (ignored) by Modules. XML data can be edited using the CMS GUI. For Non-XML data (Assets), there will be different functions. Non-XML data needs to be downloadable (serialized as binary?). It cannot be transformed. It might be converted to Base64 for use as XML, but would use the BinaryToBase64 Module, which is not part of core. Assets can be uploaded; they cannot be edited using the CMS GUI. Third, there are several options for the datastore: 1. Content/Resource[Type="XML|Not XML"] My experience suggests using Elements will prove much easier (less code) than using an Attribute for something so basic. It is the difference between: <xsl:apply-templates select="resource[type='xml']"/> and <xsl:apply-templates select="document"> It is one extra test (repeated extremely often) that can be avoided by better design. 2. Content/Document and Content/Asset It should be easy to get all the Nodes of one Type. 3. Content/Documents/Document and Content/Assets/Asset This makes it extremely easy to get all the Nodes of one Type, but makes functions where the ContentType (or ResourceType) is irrelevant much more difficult. If you want a list of the latest updates, you need to search Documents and Assets separately and then merge the lists and resort the result. A simple search for Resources that have a new Revision ready but unpublished becomes difficult. And it adds a Node that exists only to categorize other Nodes; I cannot think of anything useful to add to these extra Nodes. Fourth (repeating #2), regardless of how they are stored, programming requires separate classes because too much functionality is different. Identification, security, language support, workflow, and relations can be handled by the superclass, but how they are used within Lenya and how they are sent to visitors is very different. Why store them in a struture that requires extra programming throughout Lenya? solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
