My XML based application may not render the data at all - it might just use the data to perform some other functionality - lets not get too fixed up on the visual representation.

OK, you are probably correct.

XSL is based on XSLT which is a means of taking an XML document and producing another document from it (not necessarily XML). XSLT currently supports three output methods - XML, plain-text and HTML.

Thanks for the insight into XSL and XSLT. I think I understand the context much better now; I was really thinking in terms of stylesheets alone.

The problem is really that I believe using XML is a good idea because it allows reuse of existing tools, but then I really don't have any experience with an existing tools other than IE5, which does not do much. That in principal it is always possible (and necessary) to write custom applications for custom functionality is quite understood.

However, it would be nice to have generally accepted mechanisms, that allow to use certain feature right out of the box.

When I was asking about how to manage free text with markup and data _efficiently_, I was thinking about how to use standard tools (which don't exist that much yet) to edit the different views of the data, much more than thinking about reporting/screen display with a stylesheet.

---

Also, I think I did not do a good job in explaining where I see the problems (which may be due to my lack of understanding XML). Lets go back to examples. Markup of the text:

leaves usually obovate (except in young leaves), 3 cm long

could look like

<leaf>leaves <shape> <frequency modifier>usually</frequency modifier> <categorical value>obovate</categorical value> <reportable note>(except in young leaves)</reportable note> </shape> , <length>3 cm<length> long </leaf>

Thats already quite complicated. But how do I add the data? The data contain, e.g. an identifier for obovate (i.e. an alphanumeric code or some GUID) to identify the term obovate in relation to some character schema. Note that the character schema may use the term obovate as identifier, so it could be identical. However, German, Chinese, or Russion descriptions will have quite other text within the markup...

Further the data would contain more detailed information what frequency "usually" really is, where the original information has been stored, it may contain in addition to the 3 cm information whether "3 cm" is a single measurement, a guess, or the average of 30 measurements, for each of these informations.

Yet another level is the knowlegde management, with authoring, editing/revision, quality control, multiple annotations etc.

Welding all this into the above structure is quite complicated, so I am looking for general guidelines, how this can be achieved efficiently. My feeling is, that attributes within elements are not the solution, but I may be wrong. In Don's example

<leaf shape="obovate" length_mm="31"/>

It is difficult to add information about obovate or length. Noel already noted that we may be running into this "properties of properties" problem.

General question: Is there any reason why attributes exist at all? What is the advantage of

<leaf shape="obovate" length_mm="31"/>

over

<leaf> <shape>obovate</shape> <length>31</length> <MeasurementUnit>mm</MeasurementUnit>=" </leaf>

?

Gregor ---------------------------------------------------------- Inst. for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Gregor Hagedorn Net: G.Hagedorn@bba.de Koenigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203

Often wrong but never in doubt!