On Sun, Jun 25, 2006 at 02:49:56PM -0400, Jay R. Ashworth wrote:
On Sun, Jun 25, 2006 at 12:14:06PM -0600, Chad Perrin
wrote:
The
distinction I'm accustomed to seeing made is between "semantics",
the meaning of things, and "presentation", the way that meaning is
wrapped in a look, to convey it to the user.
Yes, and there's a difference between basing presentation on semantics
and creating a semantic class of presentation. In one case, you have
presentation classes based on their presentational characteristics, and
associate your semantic classes of content with those classes of
presentation, and change the associations when you want to modify how a
semantic class of content is presented. In the other, you define a
semantic class of content as having specific presentational
characteristics, which lends itself to the likelihood that you will end
up defining three or four semantically-identified classes of
presentation that all have roughly the same presentational
characteristics, providing greater probability of violation of the DRY
principle of design -- which can get messy rather quickly.
Unless I'm misunderstanding you, you're suggesting that the concept
that there might be many different tags, for different categories of
source material, but which we want all to render in the same fashion,
is *bad*.
Well . . . yeah, kinda. At least, I don't see a reason that it would be
good, and plenty of opportunity for it to be bad.
I might have accidentally assumed familiarity with a concept that may
not be familiar to you: mea culpa. I'll try to fix that now.
DRY = Don't Repeat Yourself
Unnecessary repetition leads to unmaintainability, because when you need
to change one thing you often end up having to run around changing it in
numerous places, and sometimes people miss things.
I'm not saying we shouldn't distinguish between content semantics. I'm
just questioning the decision to tie presentation characteristics
directly to semantic classes of content.
If I understood brion correctly, we're not: that will be handled in the
CSS.
I suppose I should probably just look at the source code for all this at
some point and get a better idea of what's going on behind the scenes.
I'm
also curious as to why a
database query (for example) would care that it's fetching a poem, as
opposed to a fondue recipe: I was pretty sure we hadn't developed DBMSes
that have aesthetic taste just yet.
I believe the answer to that is "ask the Semantic MediaWiki people",
though I'm not sure.
But the point isn't the DBMS.
It's programs people later write to crawl the data, and do statistics
on how many poems we have, etc.
Ahhh, that makes more sense. Sorry, I guess I just didn't get what you
were trying to say.
That's a good point. Tag properties may not
be the best way to handle
it. In fact, there's no reason that a simple tag syntax can't be used
for semantic markers, and that these cannot be used as cues for applying
presentation styles. What concerns me about this is that it seems the
way we're implementing a tag syntax for semantic markers is by actually
making the semantic markers and presentational style cues synonymous,
rather than merely associated (and decoupled).
Ah. No, as I say, if I understood brion correctly, it's a CSS thing.
That doesn't necessarily mean they're "merely associated (and
decoupled)", though at least it's not being handled via direct
characteristic definitions for XML tags -- which would probably be a Bad
Thing for purposes of later maintainability.
To further muddy the waters of the use of the
term "semantic":
I'm not worried about the syntax of assigning semantic markers and
presentational styles. Rather, I'm considering the semantic structure
of our markup, and how best it can be planned out for future
maintainability. It looks to me like extensions to the semantic
structure of the wiki markup are being implemented as features, when
such should instead be approached as core functionality. After all, the
parser is an implementation detail: the language definition is what
makes the parser worth using.
Ok, I'll admit to having completely fallen off the wagon on that last
graf. Could you expand?
I'm speaking of the syntax and semantic structure of languages (thinking
of programming languages as my usual example, though markup has roughly
the same division of design characteristics). Um. I'm basically saying
that I don't care too much about the actual appearance of the markup we
use, so long as it's vaguely readable and somewhat consistent (and,
preferably, doesn't make typing a chore with lots of underscores and
tildes) -- instead, what I care about is the rule set for the language,
on which that syntax is built. For instance, there's an underlying
structure to romance languages (Italian, et cetera) that is different
from that of a language like Japanese. One cannot simply swap out words
one-for-one in Italian to make Japanese: rather, one must rearrange the
structure of the sentence, certain parts of speech exist in one language
and not in the other, and so on. The latter is characteristic of
differing semantic structure for a language.
I'd like to see a consistent semantic structure that lends itself to a
consistent syntax that in turn lends itself to maintainable use.
--
CCD CopyWrite Chad Perrin [
http://ccd.apotheon.org ]
"A script is what you give the actors. A program
is what you give the audience." - Larry Wall