[
Lists Home |
Date Index |
Thread Index
]
Unfortunatelly, it would be very difficult (if not impossible) to
introduce and get a new namespace mechanism accepted by the industry and
standards forces.
<flameproof>
If it counts to anything, what I dislike about namespaces is that there
is no formally accepted relationships between (e.g.)
http://www.mydomain.com/ns/base/
http://www.mydomain.com/ns/base/module1
http://www.mydomain.com/ns/base/module1/submodule
as a way to organize vocabulary modules.
Another missing part is a formal scheme for URI versioning...
</flameproof>
Cheers,
Manos
Jeff Lowery wrote:
> Wait a sec while I change into my Nomex suit...
>
> I'd like to propose a mechanism for minimizing namespace hassles while
> maintaining readability. I expect this will raise hackles immediately, but
> hear me out:
>
> The mechanism for declaring namespace prefixes seems to be the primary
> failure point for namespaces. The association by scope of a prefix and it's
> declaration gives rise to all sorts of mischief when scope changes during
> document manipulation. Add default namespace declarations and things get way
> too interesting sometimes.
>
> All-in-all, given the design motivations of the WG, the basic mechanism is
> sound on a syntax level. Unfortunately, it creates dependencies withing a
> document that then need to be managed both internally and externally. Is
> there a way to manage these dependencies better, make them more
> idiot-proof?
>
> My opinion is that the answer lies in a prefix registry. I know that's
> controversial, mainly because it creates an authority structure that has to
> be consulted prior to assigning prefixes to names. I think this can be
> mitigate, though, by having a provisional namespace prefix mechanism that is
> essentially the same as it exists now, minus default namespaces. Registered
> prefixes would then be denoted by special naming conventions.
>
> The advantage of a registry is that prefixed names become universal names
> when prefixes are registered. There are no scope issues. The primary
> disadvantage of registration is that there will be a prefix rush. I don't
> see a dependency on access to the registry at parse time, unless there are
> resources to be associated with the prefix (such as a URI to a RDDL doc)
> that the parser needs.
>
> And, lastly, default namespace declarations would have to go...
>
> I'm sure this is not a new proposal, but it's been at least a year since it
> was shot down last time... :-} Those permathreads need regular wear or
> they grow stiff.
>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|