[
Lists Home |
Date Index |
Thread Index
]
Sean McGrath wrote:
> I suspect they are in the twilight zone between the two in an area the database world typically calls a
> "view". i.e. you have physical tabular structure but all interactions are performed through database
> "views". These are more aggregational than presentational. They go through a further binding to create
> human-oriented presentations.
These views are what I generally refer to as instantiated data structures, in part to make it clear that
their form, including datatypes, is hardcoded into, and therefore dictated by, the programs which expect to
operate against them. This differs in part from the expectation in the case of views that a database engine
will be the intermediary handling their presentation, whether or not they are instantiated specifically to
be consumed by a program. In writing application programs on top of a database engine, we design data
structures for the application code, and we design corresponding views to be presented by the database
engine. This permits each instance of the latter to be consumed immediately as a case of the former.
I suspect, though, that our experience of viewing marked-up documents in browsers and indeed of
understanding XML instances as integrally documents has given us notions of presentation which differ from
views in the database world. An XML document is accessible to humans, and has more visible uniqueness and
integrity, than raw database tables. It seems more normal for the apparent structure of such a document to
color its presentation than it would seem for relational tables to do something similar. The browser
reinforces this preference and has habituated the great majority of users to it. We expect generally to see
the document on its own terms, displaying its own order and structure. 'Presentational' elements are
regarded as decoration hung upon that document to style it in a particular way.
On the other hand, database views ignore how data is factored into tables, in favor of the specific
structure required by an application program. The data required is pulled into the structure expected by a
particular use, rather than an explicit structure reworked, and its details restyled, to a data supplier's
expectations of what its data consumers will want. In creating database views the indices and joins on
which the tables are maintained are ignored in favor of the structural result desired. Yet in pushing a
styled presentation from a markup document, neither the link structure of the original document nor the
attributes on which that document is anchored within a particular context will generally be much altered,
let alone ignored entirely.
Therefore, while I agree with you that database views are a good analogy for the styling or presentation of
markup content, it is only with the understanding that the mechanism is the reverse--pull to the particular
expectations of a consumer rather than push from the expectations of the supplier. And since a 'pushing'
document is largely incapable of transcending or ignoring its own structure and data context, those aspects
of its self-conception are exported as content, however strictly presentational they might be in the
different context in which that content is consumed.
Respectfully,
Walter Perry
|
