Thorsten Scherler wrote:
El mar, 07-02-2006 a las 14:24 +0100, Andreas Hartmann escribió:
[EMAIL PROTECTED] wrote:
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".
Yes, and neither of them seems to win.
Now you suggest "Asset" right after a discussion that
wanted to define Assets as parts of a Document.
Yes.
<snip stuff I agree/>
Now I can understand solprovider, when the term asset is used in 1.4
different then in 1.2 that will cause confusions.
I recommend the term "nugget". A (content) nugget is an atomic part of
information. This nuggets can be images, audio files, xml snippets of
information, plain text,... Content is an aggregation of (content)
nuggets.
i'm fine with that. there is a need for new terms and concepts. either
we spend a lot of time explaining how terms change, or we invent new
ones and deprecate the others.
you are right, our "asset" has become a "liability" :-D
what i don't like about "nugget" is that it has no common meaning
outside of lenya, so people can't infer the concept from what they
already know. so i'd rather stick to asset and make it very clear in
READMEs and all over the place how the meaning of asset has now been
generalized (it's not a wholly different concept, just a broadening, so
imho it's ok).
Like Andreas already pointed out I do not see the need for the
differentiation between Non-XML and xml data since a suitable editor
may/is "just a module away". ;-) A SVG image for example can be both an
editable xml file and a binary png (svg2png serializer).
Further for me a document is a presentational representation of content
aggregation for a certain format (Andreas uses the word "view" for this)
and I have sometimes the feeling that if we talk about documents we are
talking about the html representation.
What both models of http://wiki.apache.org/lenya/GlossaryStructure have
in common is that "content" is stored 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.
A toc normally lists the chapter of the book, each chapter can have
subchapters, ... In chapters you can use arbitrary (content) nuggets
(illustrations, analysis, ...).
IMO if we now have reached the point to question our naming, why not ask
whether publication is the right name?
I see it like:
Publication = book
sitetree = toc
document = chapter
asset = (content) nugget
book does not cut it. it's very uncommon in the context of web
publishing. chapter collides with "page" (in printing, a chapter
contains of one or more pages, in web publishing, a page is more like a
"chapter").
if these need changing at all, i'd vote for
site
site tree
page (taking the place of andreas' "document")
asset
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
