On 2/4/06, Jörn Nettingsmeier <[EMAIL PROTECTED]> wrote: > * "document" as currently defined on > http://wiki.apache.org/lenya/CMSTerminology feels awkward, because it > subtly re-defines a term that everybody thinks they know. (plus it seems > not to reflect the most recent state of discussion.) > > i think we should consider that what we now call "document" is basically > a container of language versions and their assets (and possibly their > revision history), and adjust our terminology accordingly. > i don't like "content item", because to me it sounds more like a small > snippet, such as a media asset file. and it makes me think of a leaf > node rather than a container. it feels like a stopgap word that i'd hate > to have around forever.
That sums up what I have been attempting to write. > as a workaround, i have used the term "document id", but it's not much > better. DocumentID is a property of a Document: the primary URL. DocumentUNID is a property of a Document: the flat storage key. > there is also "site tree node", which is somewhat analogous and > my current favourite, unless we allow multiple hierarchies, when it > suddenly becomes orthogonal and plain wrong. I am pushing for dynamic Sitetrees are generating data similar to 1.2's sitetree.xml. A Sitetree Node is a node as used in menu.xsl and other Navigation Elements. > maybe it should just be "document container"? Please no. > * "language version" does not stand well on its own (version of what?), > it clashes with "version" and totally explodes when you talk about > "language version versions". i suggest to call it a "document", since > that's what most people will intuitively do. in the case where we need > to make i18n issues explicit, we can talk about the "document" (in the > default language) and "document translations" (the other languages). or > maybe even "document versions" belonging to a "document container" (or > better yet, to a "site node"). Thank you. You found the word we needed. Forget "Language Version" and "Document Language Node". I like "Translation" much better. It implies Language without requiring multiple words. > * let's ditch "version" for old states of a page. instead we can use > "revision" consistently throughout, which is a lot more precise. "Version" was gaining acceptance, but I agree with you for very different reasons. "Version" is used by JCR for versioning, so datastore Nodes have "versions", but "Documents" have "Revisions". Our structure can be: Document/Translation/Revision > * i would prefer "document type" instead of the current "resource type", > because it is already in common usage (everybody knows DTDs). it does > not quite include the processing part, but that trade-off is worth it > given that it will give most people a precise idea of what it is. > we can introduce the additional term "document type handler" for all the > involved xslt and usecases, and summarize it all as a "document type > module". Depending on whether we decide on "Resources" or "Content" for the collection of "Documents" and "Assets", then either "Resource Type" or "Content Type" will have two possible values: "Document" or "Asset". "Content" seems to have won. "Document Type" refers to the XML DTD used for a "Document", and should have values like "xhtml", "blog", etc. > * we currently have problems with "resource" and "item", because they > are so generic. let's avoid re-defining them for concrete concepts. doc > writers need good and unpolluted terms for abstract concepts sometimes. We are renaming Lenya 1.2's "Resource" to "Asset" to match the GUI. "Resource" was proposed as an alternative to "Content" for the collection of "Documents" and "Assets", but most prefer "Content" because it matches "CMS". "Item" has been suggested in multiple word names for various definitions, but I hope those are gone. If "Item" is used, I want it to mean a "Document Element". Summary: - Publication - - Content - - - Document (has Type, DocumentUNID, DocumentID properties) - - - - Translation (has Language and LiveRevision properties) - - - - - Revision (has CreationDate and Editor properties) - - - Asset (has Type, UNID, ID properties) [- - - - Translation (has Language and LiveRevision properties)] - - - - - Revision (has CreationDate and Editor properties) Will Assets have Translations? Can it be optional? How do we handle PDFs in multiple languages? One Asset per language? Or one Asset with multiple translations? solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
