On Sun, Jun 25, 2006 at 11:53:30AM -0400, Jay R. Ashworth wrote:
On Sat, Jun 24, 2006 at 10:15:47PM -0600, Chad Perrin
wrote:
In retrospect, the argument about what constitutes "semantic" tags could
go either way. I was thinking presentational semantics and you were
thinking of semantic presentation, basically. Yes, that's a meaningful
sentence.
It is?
:-)
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.
While many meanings may carry the same look, the reason people suggest
that the tagging should reflect the *specific* meaning in each case is
so that back-end processes which might want to can distinguish.
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. 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'm not sure I agree that semantic
presentation is really a great idea
to implement in markup tags. Rather, it seems to be something that
should be managed via properties that are attached to tags. It provides
sort of a natural hierarchical inheritance model, rather than (by way of
analogy) sticking every single file on your hard drive in the root
directory, like the FAT12 filesystem did.
Well, as long as the tags are distinguishable, yeah, but it seems
easier to do <poem> than <special type=poem>, particular in the
Wikipedia milieu.
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).
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.
--
CCD CopyWrite Chad Perrin [
http://ccd.apotheon.org ]
This sig for rent: a Signify v1.14 production from
http://www.debian.org/