Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: escaping QName interlopers
 > uche.ogbuji@f... (Uche Ogbuji) writes: > >> jcowan@r... (John Cowan) writes: > >> >For RDF purposes, at least, the QName to URI mapping is done by > >> >concatenating the namespace name with the local name, so that if > >> >xmlns:xml is "http://www.w3.org/XML/1998/namespace" then xml:space > >> >is "http://www.w3.org/XML/1998/namespacespace". This is ugly, > >> >wherefore most RDF-related namespace names end in either "/" or > >> >"#". IMHO this is a fine convention. > >> > >> IMHO this is a pathetic hack, and something unlikely to persist as > >> any kind of official conversion. Its complete lack of coordination > >> with "how URI syntax works" per RFC 2396 is nothing short of > >> hilarious. > > > >What is a "pathetic hack"? > > String concatentation as the answer to QName/URI mapping is a pathetic > hack. It pays no attention to the structure of URIs, it isn't > reversible, and it's easy to come up with broken cases. Ah. You're quite right about this. If URIs are to be so important to XML, there should probably be some mechanism for at least declaring sane URI operations for XML systems. How this would be spelled I leave to someone else. > >As Tim Bray pointed out, John Cowan is really referring to two very > >distinct matters above. > > I find the underlying concatenation approach broken enough that the > difference between the two cases is a matter of poor or poorer. I think the slasher approach's main improvement is that the namespace is actually a valid base URI, which means that in many practical cases the concatenation is at least equivalent to relative URI resolution, whereas in the hasher POV, there is no way to even recognize a valid URI operation. > >As always, I think that the "slasher" point of view does indeed > >correspond with URI, whereas the "hasher" POV often does not, although > >it can be stretched, with enough weasling, to look as if it does. > > The slasher point of view could potentially be brought into > correspondence with URIs provided that someone took the time to define > that correspondence and outline cases (like any namespace URI that > includes a fragment identifier) where it doesn't work. True. > The "hasher" POV seems to come from a view that's forgotten that hashes > indicate fragment identifiers, and that fragment identifier > interpretations are bound to representation media types. It's difficult > to justify that approach if you have any recognition of URIs as having > features beyond a sequence of characters corresponding to some EBNF. > > I really wish there was a good way to illustrate how funny URI > conversations are, in a Waiting for Godot kind of way. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Python Generators + DOM - http://www.xml.com/pub/a/2003/01/08/py-xml.html 4Suite Repository Features - https://www6.software.ibm.com/reg/devworks/dw-x4suite5-i/ XML class warfare - http://www.adtmag.com/article.asp?id=6965 MusicBrainz metadata - http://www-106.ibm.com/developerworks/xml/library/x-think14.html 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
