There must be some misunderstanding here. My argument was 1) introducing
format negotiation for table does not justify the cost and/or solve the
problem. 2) an old net convention is useful in transition period and we
should see it being applied appropriately. I am not advocating a paradigm
shift.
>|>can't handle is a bad idea on the face of it. Please imagine what
>|>this argument would look like if translated to compiler design,
>|>database design, or any other kind of computer processing that expects
>|>structured input.
>|
>|Weak argument based on a weak analogy -- they don't translate.
>
>guess that the great majority of people coming into this for the first
>time feel pretty much the way that you do, like student programmers
>who don't see why "purists" insist that it's better to write
>structured code. (You may not see the analogy, but those of us who
>were around twenty years ago when inspired spaghetti code was the norm
>remember that that was exactly the way that even the professional
>programmers felt about it.) Certain kinds of constraints make sense
>only when your projects reach a certain size. Until then, you don't
>see the point, and it's hard for others to explain it to you.
I happen to understand this (I think :). As I see it, the history of
software engineering is a evolutionary history of management of dependency
and reusability. What purists can't see is that there is a trade off
between the scale/granularity of abstraction and the cost of abstraction
maintenance.
>Today I put 28,000 pages of material online, bringing the total I have
>put on our Pubs Web server over the last few weeks to somewhere in the
>neighborhood of 110,000 pages. This task, based on five years of
>development, would have been quite impossible if the material had been
>tagged according to the ideas you are promoting. Unfortunately, I
Good for you -- that's really an awesome job. On the other hand if your
page generating software is written in a modular way, it's trivial to add
compatible table support as in my examples in the table generator. If this
is not trivial, it would imply a bad design in your page editing/management
software.
>don't have the energy left to try to prove this to you. It will prove
>itself when you engage in such projects and have to maintain them over
>a period of time.
>
>This probably won't strike you as a very good answer to the points
>that you have raised, and I certainly won't blame you for persisting
I believe you explained yourself very well (thank you) concerning a
possible abuse of an old net convention/wisdom. But the possibility of
abuse does not justify the exclusion of its useful/cost-effective
application.
>in your present view. But perhaps you will forgive some of us if we
>decline to adopt your "Duplication of Ignorable Tags".
BTW, this DOIT technique was intended to be a joke/humor, I remember
I put a smiley there...:)
regards,
__Luke
-- Luke Y. Lu mailto:ylu@mail.utexas.edu/ http://www.utexas.edu/~lyl/