|
On 5/6/2017 11:09 PM, an off-list troll wrote: [Comments deleted because the writing style would identify the troll and I'm not quite angry enough to do that.] Simple-minded? Apparently stacking teacups on teacups by building specs on top of unstable specs is still considered brilliance in some quarters. While it's unfortunate, the lack of structure - I'd even say deliberate lack of structure for political reasons - of URLs and URIs is a known problem that programs and people have had to deal with for a very long time. RFC3986 is a largely failed attempt to make too many contradictory decisions over those decades make some kind of sense. The strange derangement that led us to "URIs are purely identifiers and who cares how they're constructed" for a while has left us in a difficult place. That difficult place is, however, quite tolerable until we try to shove URIs into places where developers expect that structure. The xml:base conversation is an all too perfect demonstration of that. To provide a shortcut for document creators, the W3C decided to stuff these not very structured strings into an environment where people expected structure. I'm not sure whether the shortcut has more benefits than the costs, but conversations like this one certainly count as costs. So yes, URIs have flaws, though developers have worked around them successfully for decades. Congratulations to the IETF and W3C for botching what started out as a comprehensible approach, and to the W3C for putting those flaws under a magnifying glass by using them in a context where their failures are magnified. We could have avoided the shocked faces by leaving URIs where developers can deal with them, rather than stuffing them into xml:base and letting everyone wonder how that's supposed to work. xml:base should probably go away, though we all know how easy that is. Thanks, Simon |