[
Lists Home |
Date Index |
Thread Index
]
"Nicolas Lehuen" <nicolas.lehuen@ubicco.com> writes:
> Beginner's question : what is the difference between
> an architecture and a namespace ? Is it that
> architectures have a meaning (i.e. meta-DTDs and
> possibility to write code that process the AF
> following these meta-DTDs) and allow renaming,
> whereas namespaces are just sets of names ?
I guess so. That's one way to describe at least some
of the difference, anyway.
The computer science-y-ness of XML Namespaces is fairly
irreproachable. Only trouble is, XML Namespaces have
always been promoted by the W3C as the solution to a
fundamentally philosophical problem, and XML Namespaces
cannot fulfill that role.
For me, the real issue is the nature of the impact of
the XML Namespaces paradigm on the marketplaces for
software and data. To put it as kindly as I can, I
claim that the impact of XML Namespaces cannot be other
than suboptimal, from the perspective of human society
as a whole. We can do *much* better.
If we want to do better, the first step is to adopt an
attitude that the designers of XML Namespaces were
evidently determined to avoid adopting:
* SEMANTICS ARE CENTRAL.
* NAMES ARE JUST HANDLES FOR SEMANTICS.
The "architectural forms" paradigm puts semantics at
the center of the stage. The DTD is merely a way of
naming semantics and constraining their interchange
syntax. The only reason to provide syntactic
constraints is to make sure that the semantics can be
interchanged reliably. In the architectural forms
paradigm, a DTD is just one aspect of a governing
"architecture definition document (ADD)" -- the ADD is
the *central* thing; everything else is technical
details. Normally, the ADD is written in a natural
language, such as English. (It could also be expressed
in something like CycL, I guess.)
> Is all
> the discussion about namespaces due to the fact that
> for many, namespaces should have the same meaning as
> architectures (i.e. contain meta-schemas and allow
> element and attribute renaming) ?
You're focusing on details, here. The details are
important, but only insofar as they reveal that it is,
after all, possible to solve the problem that XML
Namespaces are incorrectly claimed to have solved.
> Disclaimer : I just read David Megginson's
> documentation of XAF [1], which implements a subset
> of AFs for XML. I'll try to read [2] in the future,
> especially for the meta-DTD part, but right now my
> brains just melt at the idea of reading a document
> which calls its sections 'subclauses'. Apparently
> those people like giving complex names to trivial
> concepts :P.
It's all in the interests of precision and clarity.
In my 16 years of standards work, I've learned that if
you want a standard to work, you have to think like an
engineer. But if you want it to be adopted, you have
to think like a politician. The two mindsets are
sometimes incompatible. Where they were incompatible,
I've generally chosen to make the standard really work,
in preference to early, easy adoption. For me, it's a
professional thing.
The other approach, however, tends to enjoy quicker
success. It is not an accident that the notoriously
vague French language is the traditional language of
diplomacy. For some reason, vagueness is generally
more palatable. I regret that the precise language
that I, among others, have labored to produce is so
off-putting for so many people. I know no other way to
make a standard that can withstand the stress of
implementation and deployment, while actually meeting
its original requirements.
> : it's because some of us are here to learn, and you
> : can teach us :) !
What a nice thing to say!
-- Steve
Steven R. Newcomb, Consultant
srn@coolheads.com
voice: +1 972 359 8160
fax: +1 972 359 0270
1527 Northaven Drive
Allen, Texas 75002-1648 USA
|
