[
Lists Home |
Date Index |
Thread Index
]
8/19/2002 12:10:36 PM, "Simon St.Laurent" <simonstl@simonstl.com> wrote:
>I think a strictly pattern-based approach would offer context - both
>ancestor and descendant context - as an answer to that, though context
>can occasionally be misleading or abused.
>
That's presumably how humans cope with the problem of distinguishing
"tables" from "tables". People know better than to do this, but
most could understand a sentence like: "We need to table the discussion of
how to format the table for our catalog of tables." No URI's needed!
Obviously humans do this with an immense amout of built-in context, but
with sensible markup design, it could be possible, (with heuristics rather
than logic, admittedly) for a machine to figure out that "table" in the
context of a <meeting> refers to the act of postponing, "table" in
the context of <html> or another presentation lanugage means a
rectangular layout, and "table" in the context of
<furniture> means a physical table.
Identifiers and logic about them obviously has its place in software
and markup, but I take Simon's post as recommending that we pay
equal attention to patterns and heuristics. To use my favorite
example, real clerks aren't stymied because an order comes in on
a form they've never seen before. They look for the patterns they're
used to ... and "throw an exception" only if they don't find the
information they need. Obviously strong typing "contracts" make
lots of sense to improve efficiency in more tightly coupled systems,
but not at a cost of losing customers. Anyone who rejected an order
because the HTML description section contained a <ul> inside a <p> would soon find
themselves unemployed!
|
