[
Lists Home |
Date Index |
Thread Index
]
Yes, and Paul makes that point and I agree. We know that
despite all said that syntax and names are merely declarative,
in any tag stacking application, change the name and the
semantic may or may not change (it might be an alias). XML
doesn't care but the application does. One does want to
make that more predictable and one does want to educate
customers that a change of namespace is not too dissimilar
from demanding a new version of the software; say $$$.
It also means that private control of public namespaces is a
real and growing problem for the users and vendors.
The problem is not being clear about the implementation
framework. Two things that might help would be simple
language that states the reality of implementation (eg,
yeah, it's a GUID of sorts) and then a best practice
that states wherever possible, keep something at the
URL end of the URI. I can see a counter argument where
the XML is dynamically generated, but wherever there exists
a reasonable chance it will be displayed to the user in a
browser context (turns blue and is clickable: in other
words, wherever the environment makes a control of it),
then a RDDL or RDF document is advised as the target
of the hyperlink.
len
-----Original Message-----
From: John Cowan [mailto:jcowan@reutershealth.com]
"Bullard, Claude L (Len)" scripsit:
> First, the relationship between a namespace name
> and the implementing semantic must be made clear
> instead of silent. Implementors must not be surprised
> that if the namespace is changed, some code starts
> to fail.
Some people would be surprised if code failed when the localname
changed, too. The namespace-name is part of the name: if it
changes, the name has changed.
|
