David Carlisle wrote:
> I suspect
>that having some intelligent input at the start of the process may be
>more effective than having to try to hand correct any mistakes made by
>this inferring process.

This is supported by David Hunter

<quote>I'm thinking that you might consider doing it the other way around.
That is, instead of using XSL to "analyze" the XML document, load it into a
DOM and figure all of this stuff out from there, in whatever programming
language you're familiar with.  (After all, this sounds more like straight
programming than transformation.) </quote>

and Oren
<quote>You are better of using a SAX
parser in combination with some conventional programming language for
collecting and analyzing the data - Java, Perl, and Python come to mind (in
no particular order :-) </quote>

>Of course you can do a bit of both, have a basic DTD that infers from
>zero knowledge that you may include into a stylesheet that has 
>templates
>for particular elements. So you can hand code any elements 
>that you _do_ know about, then let the system do something with the rest.
>


OK, taking this approach, use a DOM based approach first off, the questions
to be answered are, if I'm thinking right, very XPATH'ish in some respects,
but I'm a little stumped as to what questions to ask and how to 
interpret the answers, for other areas, e.g.

Any suggestions as to the questions I might ask to get a feel for 
whether or not an element is a container/block element or
in-line?

Thanks for the responses.
The usage is for Visually  impaired users accessing an XML
web page, some time in the future.

Regards, DaveP


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list