[
Lists Home |
Date Index |
Thread Index
]
Ok. Ugly is a data point. AFs as currently defined
are ugly when used with attributes. Namespaces make
XSLT ugly so we just discovered that the law of the
preservation of complexity can be renamed to the
preservation of uglyness. Call Revlon. :-)
Namespaces at that time were disambiguators (yechh,
but I have to go fast). AFs are mapping constructs.
Namespaces let one build a so-called, compound document,
but actually, just get rid of naming collisions and
at the same time, make DOCTYPE somewhat worthless. Both
associate a name to an external resource of some t...
errm.... this always goes south in this part of the
discussion. Urrp ugly S meets ugly T and make ugly
children.
But both are just means of association with respect
to semantics. And we don't have a standard means
of describing semantics.
No matter how we slice this, James is right. If we
want to associate semantics/behaviors, something
more layered has to be at the other end of that
association.
o A DTD is pretty good for validation,
but not co-occurrence constraints. Neither is Schema
although schema gets us part way there. Association
mechanism aside, we'd have to do better than DTDs
or Schemas as Rick elegantly points out with Schematron.
o AFs seem to be a stronger association means, but we
could possibly have alternative means and still
be productive. But what is an "enabling architecture"?
RDDL is an approach based on the namespace mechanism.
AFs point to "enabling architectures" but I'm
not sure what those are except it says they are or
can be DTDs. I feel like I'm in a self-refential
loop here.
Because as Eliot Kimber noted, AFs are "documented" I assume
they are equivalent to the human-readable parts
of RDDL. Yes? Docs is Docs. AFs can be inline
as PIs and that is slightly better than namespaces
because we don't have to associate via atts that
invade the content, or get around that with baroque
rules for inheritance which are system-specific so
again, invasive. On the other hand, they work in
deployed systems. (I feel like Tevye in Fiddler
On the Roof, suddenly...).
So far, tie game with the exception
that the namespace uses the URI and therefore
has a system-specific but widely available means.
AFs are proven to work but the means isn't widely
available. That doesn't mean it can't be; it
just isn't. It means AFs need a more compelling
marketing strategy or a cleaner way to say
"enabling architecture". The "enabling architecture"
is the thing we are after here, yes? RELAX gives us a
stronger DTD? That's a good thing, but not the
whole thing. Where will the ISO group propose
for the rest?
How many options can we afford to preserve? Do
we need:
1. Multiple means of associating semantics
2. Multiple means of expressing the semantics
Are these the same problem or the difficult
by multiplicity (too many ways to do the
same thing in only slightly different
circumstances)?
len
-----Original Message-----
From: Tim Bray [mailto:tbray@textuality.com]
At 08:57 AM 31/01/02 -0600, Bullard, Claude L (Len) wrote:
>The W3C also has to give up superstitions. On the
>other hand, AFs were discussed very seriously and
>I'm still not sure what the killer objections were.
In my recollection, the main objection was that the AF syntax
for namespacing on attributes was seen as really unattractive.
If we had wanted to do namespaces on just elements, not attributes,
I'm pretty sure we would have ended up with AFs or equivalent.
|
