Lists Home |
Date Index |
As Arthur tells his knights in the Holy Grail,
"Camelot! Let's not go there. It's a silly place."
On some days, that is the W3C: a bit too impressed
with its perception of its imprimatur.
As pointed out, AFs were a way to get rid of the
need to name pieces of the inlined controls and
share the names among applications. Remember,
SGML at the time was struggling with the mono-name
space aspect of DTDs and the centralization politics
that makes inevitable. Before there was an Evil
Empire, there were competing government factions,
competing industry committees and so on. Everyone
was trying to write The Final DTD and 28001 was the
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.
It may be that AFs are not THE solution, but a solution
that like so many others (relax, xml schemas, dtds,
xslt) and so on, once understood and implemented,
have a niche in which they thrive. If there are
overlaps in functionality with other specifications,
so what? That is the case already with some of
the bloomin' flowers out there. Keep XML 1.0
stable and don't require namespaces in the core,
and this all works. If XML 2.0 is a stricter
specification, it may also become a dodo.
From: Lars Marius Garshol [mailto:firstname.lastname@example.org]
So the W3C family of specifications does need something *like* AFs, if
not necessarily AFs as they are known from ISO 10744. In fact, I think
the specification mechanism from ISO 10744 should be abandoned. AFs
are, at heart, a subtyping mechanism for element/attribute types with
attached processing semantics. It may well be that the politically and
technically most feasible solution is to adapt the idea of AFs in the
form of an extension to the subtyping mechanism in XML Schema.
Of course, as long as many W3C people involuntarily make the sign of
the cross whenever they hear the term 'architectural forms' chances
are not very good.