Lists Home |
Date Index |
On Wednesday, Aug 20, 2003, at 18:46 Europe/Berlin, Jeff Lowery wrote:
>>> They're not stubs for full namespace IDs, they are the IDs.
>> what is to prevent a serializer from following the convention that all
>> namespace names must be url and all prefixes must be identical with
>> authority component of the respective url.
> The authority component being www.mycompany.com?
> If I understand you right,
> that's pretty close to Bradford' Clean Namespaces proposal >
i'm just trying to understand you.
>> if a required prefix is
>> missing it puts a binding in.
> How is it determined that a prefix is missing?
when a tag is serialized, once all identifers have been encoded, but
before the '<' is emitted, it is known whether additional prefix
bindings are necessary. basic serialization.
>> if that would lead to duplication, that
>> is a fatal error. if a prefix binding is present it enforces the
>> there is already a registry for such things, so just following such a
>> convention eliminates the "problem".
> I think the idea of having a convention for minimizing some of the
> complexities of namespace handling is laudable. Don't use default
> namespaces, place all xmlns declarations at root, don't use different
> prefixes for the same namespace, etc. I think we could get a
> agreement on that list of recommendations.
> The problem is that no implementation of any sort of horizontal-market
> can rely on such conventions.
no, but if you can guarantee that's all you construct, and that your
serializer follows those rules, no one "needs a brain" to cut and paste
> Neither can standards-writing bodies, whose
> specifications get all the more complex because of the idiosyncrasies
> introduced by namespaces.
>> "brain-dead". your characterization.
> I dunno. Whatever happened to the hallowed principle of making things
> simple and idiot-proof as possible,
go ahead and take another tack on postel, always emit a subtype.
> then adding modular layers of
> ever-narrower niche functionality on top? Yes, it's great to make fun
> people deemed less technically proficient than ourselves, watch them
> trip up
> over all sorts of silly 'obvious' things, and then wonder why they
> want to master our all-powerful creations. Hell, we spent years
> learning the
> intricacies of the technology, why can't they? Lazy morons.
> Of course, if you're merely arguing that the XML universe as it sits
> is only about as complex as it needs to be, there's really no point in
> further discussion. If you want to say the costs of fundamental change
> overweigh the benefits of simplifying, then I really don't have
> anything to
> say, either, as you could be right. Tough call, IMHO.
no. i'm saying you don't have to change anything to get what i
understood that you want.