[
Lists Home |
Date Index |
Thread Index
]
james anderson <james.anderson@setf.de> wrote:
| In whatever grade of esteem one may hold the Namespaces in XML recommentation,
I for one hold it in utter and complete contempt.
| it specifies that a conforming document may contain lexically identical
| qualified names which identify more than one universal name depending on
| context as well as lexically distinct qualified names which identify the
| same universal name - the synonymy/homography issue.
Yes, but the point (as far as I can discern from the spec) is that only
the resolved/expanded/whatevered "universal name" is relevant post-parse.
Inter alia, this would mean that the revised DTD syntax is not required to
use (or identify) the specific colonifying prefixes in the instance.
| I have no objection to the <!NAMESPACE ...> form itself.
I don't see any reason to have it except to infect DTD syntax with
colonification.
I'm reminded of one of the examples in the earlier drafts of the Namespace
spec. The specific context was about using the Visitor pattern as a model
for processing. The following exchange took place:
:>> Now you are saying that in order to solve the relatively common problem of
:>> wanting to combine simple, layout-driven DTDs, we must either a) abandon
:>> the visitor pattern or b) add rules about declaration ordering or
:>> specificity numbering etc. Unfortunately, b) requires a high level of
:>> coordination among component creators, which is exactly what namespaces
:>> are trying to avoid.
:>
:> Actually, namespaces seem aimed at ad hoc combinations, with a vague hope
:> that it'll all get sorted out somehow. The draft has an example, in which
:> we find this:
:>
:> <dsig:dsig>
:> <E:Manifest>80183589575795589189518915</E:Manifest>
:> <E:Sig href="http://XXX/Joe@company.com"/>
:> </dsig:dsig>
:>
:> Why (and how) should a visitor method defined for a dsig:dsig have even
:> the slightest clue of what a E:Manifest or a E:Sig is? It might as well
:> just punt on GIGO.
: [...]
:> The point is that either the combination apparatus is controlled -- in
:> which case the resolution is also known -- or it isn't -- in which case
:> the resolution is *impossible* in the general case, visitor pattern or no
:> visitor pattern. In the one case, "namespaces" are unnecessary, in the
:> other, meaningless.
:>
: You are right that the combination must be controlled. But that does not
: mean that the combination must be controlled in the same specification
: that declares the convention. In my mind, that would be overreaching. In
: other words, the DSIG: namespace should declare what it means to have
: foreign objects within elements within its namespace.
The point, of course, is that it is completely unnecessary to "import"
foreign names in their lexical exactitude when the need for annotation
*cannot* be avoided. Names in the SGML/XML formalism are instrumental:
use them as convenient and rely on annotations to clarify meaning. The
so-called "name clash" problem is utterly factitious.
Needless to say, in the next edition of the spec, this example had quietly
gone poof.
|
