[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Impacts of lightweight topics not being self-describing
Lightweight DITA can display well enough in a live-rendering
universe if directly linked or invoked. But because of the lack of
prolog in the data model, these topics are invisible to file-based
searches that attempt to make collections based on metadata (other
than features already in the topics: doctype/topictype, XPath to
content, or filename). The baseline for functionality for comparison is a typical blog or wiki entry. The SQL schemas for this type of content [1][2] typically include:
Whether this restricted inherent data model is important or not depends on your application. It complicates the logical data access layer, which must be hybrid rather than one or the other. Regular DITA topics come close to the baseline equivalency, if used with some metadata conventions. [3] For example a microsite or landing page application, the full DITA topic is usually sufficiently self-describing (as long as you explicitly identify "feature" images as othermeta, for example, and have a convention for retrieving them). And don't use all the processing features that complicate direct rendering.[4] All noted in order to ensure that Lightweight DITA is appropriately disclaimed against user expectations for an equivalently simpler application. The current model only makes the input side simpler. Until someone needs to enter other metadata into another form. The alternative, to be weighed against the message of "utter simplicity," is that we add some of these features back in without being strictly limited by the contentEditable feature set, with the expectation of using a hybrid editor (with input fields for discrete metadata and contentEditble divs for the discourse, which is probably how a LWD editor will be designed anyway). And I think it will be soon time to get a Subcommittee started where we can begin channeling these design discussions in their own list. I'm willing to lead in the initiation of this, if needed. ----- [1] http://codex.wordpress.org/Database_Description [2] http://www.mediawiki.org/wiki/Manual:Database_layout [3]But the gaps lead me to continue thinking towards a "DITA for the Web" that breaks with strict compatibility (and therefore would not be called "DITA" when that time comes) in order to enable Web applications to use structured content in ways that the current standard inhibits. [4] https://groups.yahoo.com/neo/groups/dita-users/conversations/messages/34990 --
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]