Apache uses bar.html.fr vs. bar.html.de, etc - in other words, configured
a particular way, everything after the first . is considered a metadata
keyword which maps to a namespace containing content-type, language, and
encoding keywords. Thus, index.html.en and index.en.html would denote
the same fact that this file is an English HTML file. Obviously this is
not scalable - each of those dimensions should have its own namespace.
So, we start the long and perilous journey into the metadata swamp....
something like GN/WN's .menu files, where the metadata is laid out
explicitly and what's in the file name isn't important, is closer to what
the right approach might be.
But, these are all implementation details and largely irrelevant to HTML
and HTTP protocols. Defining a standard for this is important when one
considers cross-server portability important, which I do. Our work
environment has to be focused on portability, because it simply isn't
acceptible for us to force a client to use a particular server. On the
other hand, is defining a convention for server-side data structure too
much like reinventing CORBA?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/