- From: M.T. Carrasco Benitez <carrasco@innet.lu>
- Date: Mon, 3 Mar 1997 09:22:32 +0100 (MET)
- To: Bernard Chester <BernardC@saros.com>
- cc: "'WInter'" <www-international@w3.org>
On Thu, 27 Feb 1997, Bernard Chester wrote: > 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? The problem addressed here is language label for HTML docs. We have to design for the existing web technology (HTML, HTTP ...) with a reasonable evolution. Data could be kept in any form one wishes and it has to be interfaced to the web. > 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. Many docs are monolingual and one needs to agree on how to language label this family of docs. Another structure is needed to bound all the linguistic versions. > 2) The header should be in the content: Limits us to character stream > processing and breaks with other valid HTTP content. > I do not get the point. Tomas
Received on Monday, 3 March 1997 03:19:28 UTC