dotnet xml: I just wrote my second method that reads an XML stream with XmlReader
and spits out a instance of an object that represents the XML stream.
In effect, this was a simple recursive descent parser that uses the
XmlReader as a tokenizer.

Realizing this naturally led to the question: Are there any tools
which would let me supply a description of the domain semantics
(perhaps in XSD) and which would construct a parser shell that can
turn a (say) <Foo> element into an instance of a Foo object, leaving
me only the task of parsing the attributes and storing child elements
in the proper fields?

I did a few Google searches that didn't turn up anything, but that's
never very conclusive ....

--

[quoted text, click to view]

No, not quite. XmlSerializer will save and restore an object (if
you're lucky): I'm looking for a parser generator that knows about the
XML structure but that makes no assumptions about the data structure
you build from it.

--

[quoted text, click to view]

Sounds like you are talking about XmlSerializer.

--
Oleg Tkachenko [XML MVP, MCAD]
http://www.xmllab.net

[quoted text, click to view]

Aha, sort of "typed XmlReader". There were some talks before, but I
haven't heard of any implementattions yet. The problem is that the
benefits are still unclear - why do you need it?

--
Oleg Tkachenko [XML MVP, MCAD]
http://www.xmllab.net

[quoted text, click to view]

For much the same reasons that one uses a parser generator instead of
building a parser by hand: It takes less time to write, it takes less
time to debug, and it's easier to verify.

I spent hours getting my most recent XmlReader code to handle child
elements properly. Partly that was because my XmlWriter code was
putting a wholly unnecessary <contents></contents> layer around child
elements, but partly that was because I had trouble keeping track of
all the possible Next States. I kept running into assertion violations
or even infinite loops.

Not my happiest few hours!

--

[quoted text, click to view]

Oh, there's a pretty wide range, there, I suppose. Something like
Coco/R's annotated grammar would make some sense - a way to add
arbitrary C# code at the points in the grammar where the generator
would create a method. That way, you could update the grammar (if you
didn't get it right the first time) and regenerate the parser without
losing all your actions.

I don't have the widest experience with parser generators - there
might be other schemes that make more sense - but Coco/R's is pretty
straightforward. Sure was better than Visual Parse's vile reduction
function.

--

[quoted text, click to view]

I'm curious what API and behaviour would you expect from such "typed
XmlReader"?

--
Oleg Tkachenko [XML MVP, MCAD]
http://www.xmllab.net