OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Are we ready for the namespace ID registry, yet? (w as: Re

[ Lists Home | Date Index | Thread 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 
>> the
>> authority component of the respective url.
>
> The authority component being www.mycompany.com?

or abcd.mycompany.com

>   If I understand you right,
> that's pretty close to Bradford' Clean Namespaces proposal >

i'm just trying to understand you.

>
> http://www.tbradford.org/clean-namespaces.txt
>
>> 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
>> identity.
>>
>> 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 
> supermajority
> agreement on that list of recommendations.
>
> The problem is that no implementation of any sort of horizontal-market 
> tool
> 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 
it.

>   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 
> as
> 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 
> of
> people deemed less technically proficient than ourselves, watch them 
> trip up
> over all sorts of silly 'obvious' things, and then wonder why they 
> don't
> 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 
> today
> 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.

...





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS