[
Lists Home |
Date Index |
Thread Index
]
From: "Uche Ogbuji" <uche.ogbuji@fourthought.com>
> "Design is a kind of optimization, as Tommie Usdin likes to point out"
>
> Hah. Interesting way to put it, and quite true, but since design is typically
> the first step in development, does this cause a collision of aphorisms with
> the accepted wisdom that premature optimization is evil?
Allowing that design is not only optimization, and that some optimization
is not premature, and that "premature optimization" is contrasted with
providing an unoptimized working implementation, isn't one of the points of XP
(extreme programming) that design should be spread throughout a
projects life: i.e., refactoring. I think that accords with Jonathan's
point "until you know how you are using the markup, it is hard to
know what to optimize."
Every schema is made with a processing model in mind, perhaps implicit
(or tacet or ignorant or intuited.) Lou Burnard of TEI says that
"every DTD is a theory about a document" but I suspect every schema
is also a theory about the processing, at least at level of detailed design.
In any case, this thread is a question about design patterns rather than a
particular design/optimization. The particular design will have local influences.
It is a good question: it brings out the point that if data can be represented
so many ways, shouldn't our schema tools also treat many details
(i.e. element or attribute, fielded name or attributes) as representation
artifacts (i.e. things that can be parameterized and remapped between
different permutations easily) rather than as the core. I.e., bring out
the data model first, then the particular implementation. (This is
where Schematron is heading, with abstract patterns.)
Cheers
Rick
|
