[
Lists Home |
Date Index |
Thread Index
]
[Mike Champion]
>>People don't RTFM, much less the F****** Spec. Architectures that don't
>>support the "principle of least surprise" are going to be fragile,
>>no matter how logical and consistent their other principles might be.
>>
>>Confusion IS a danger in itself, as various spacecraft lost for want of a
>>comma, or misunderstandings of units of measurement, can attest.
[Danny Ayers]
>I agree with you 100%. But is the path of least surprise to invalidate a
>very large quantity of material that's out there, and to introduce (and
>explain) a significant revision? Or to explain the status quo a little
>better?
>A soft deprecation would I suppose be the middle path.
This is going to sound Elfish (answering "both yay and nay"), but...
1) This appears to be an issue requiring benefit and cost analysis. If the
cost of change weighs too heavily against existing processes and
implementations, is it beneficial? Or would it be more beneficial to remain
status quo? Is there enough information available to make this assessment?
2) On the other hand, "confusion IS a danger in itself" and as Len Bullard
pointed out on a parallel post, customers and users who do not understand
the underlying technologies (and philosophies) may well be confused when
something that appears to be an address fails to behave as they expect. In
the final analysis, both programmers AND customers/users are affected by
whatever methods are implemented. Which side is more capable of
interpreting and resolving the issues that arise?
Question: How much impact would a solution such as the one proposed by
Seairth Jacobs have? That is, the "Scheme-Independent Universal Resource
Identifier (SI-URI)" concept which drops the scheme from the URI
("//seairth.com/AbstractResource").
|
