- From: Bernard Chester <BernardC@saros.com>
- Date: Thu, 27 Feb 1997 22:26:11 -0800
- To: "'WInter'" <www-international@w3.org>
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