Language label

As a new-comer to this mailing list, I've been waiting to reply to this
topic until I had a chance to better understand thei issues.  After a
week or so, I'm compelled to speak.

Do NOT subsume your design to the limitations of primitive flat
character files.  This is not the direction of technology, neither is it
wise to confuse content from attributes.  

You ought not to design an approach where LANGUAGE or any other
attribute is embedded in the file.  This would be unacceptable for a
number of data formats.  We already have compound documents and object
technology in heavy use.  The data, be it HTML or GIF or applet, needs
to have an "envelope" of discriptive information.  These envelopes need
to nestable.  If there is an existing Internet specification that fits,
use it.

If you have to map your content to flat files, there are ways to carry
this attribute information, in extended file attributes, side files, or
defining a flat file envelope syntax that is processed by the viewer /
server.  If you have (as many of us already do) a database, you can keep
the information there.  Why should this issue have a different answer
than where you keep the codepage of the content?

M. Carrasco, I disagree with most of your statements -
1) there is only one language for a document: Maybe only one language to
a component, but documents can be complex and compound.
2) The header should be in the content: Limits us to character stream
processing and breaks with other valid HTTP content.

Maybe this is more obvious to me since I've worked with Document
Management Systems for 8 years.

Respectfully,
Bernard Chester
Saros / FileNet
bernardc@saros.com

Received on Friday, 28 February 1997 12:02:16 UTC