dotnet xml: Hi Folks,

Is there a good resource out there with some patterns on flexibly creating
XML documents? Basically, I need to be able to start with an instance of an
XML document, or a DTD, or a XSD, and produce something I can easily
populate with my own data and render as an XMLDocument.

I've been doing a lot of stuff where I consume web services made available
by outside companies and I'm having a hard time finding a way of doing
things that I really like. In some cases, I'm using SOAP to consume the
services, but the WSDL just calls for a string, so I have to hand build an
XML doc then render it as a string to be wrapped in SOAP for me. In other
cases, I have to build XML then send it via POST, or write it out a file and
do something with it. Half the time all I have to work with is a sample of
the expected XML I need to build.

Serialization seems like it should be the answer but some of the XML is
fairly complex and I end up spending large amounts of time creating my own
XSD files so I'll have something to feed xsd.exe. Then, I still end up with
a set of classes that are a pain to use, if usable at all. Don't even get
me started on having to build XML that isn't even well formed.

Anyway, I guess I'm done ranting. Can anyone point me toward some resource
or technology that might help? It's amazing that .Net packs so much power
for working with XML but I seem to be able to use so little of it in the
projects I've been working on. I realize this is a pretty open ended
request, but I have to believe I'm not the only person with these issues and
some of you have found or created a framework you like for generating XML.

Should I be looking at code generation? XSLT? If I try to become an expert
in XML Schemas will that help me get better results from xsd.exe?

Thanks in advance for any help or direction.

-Chris

[quoted text, click to view]

You mean something to automatically generate the XML document?
Any half-way decent XML editor should be able to do this (given
a half-way decent DTD or Schema -- which may be harder to find :-)

[quoted text, click to view]

Hah! This is quite a common problem: the client just gives you a
half-thought-out idea and expects you to wave the magic wand, pass
a dead chicken over the keyboard, and produce an XML application.

[quoted text, click to view]

That too. Sometimes you just have to take it back to them and
explain politely that XML has rules, and their files need to
follow them.

[quoted text, click to view]

I'm afraid this one is down to knowledge and tools. XML can be used
for so many things in so many ways that there can't be a single
"magic wand" application that simply stitches up the seams and makes
XML work.

I tend to model the application structure in a DTD, because it's fast
and easy, open an empty instance in an XML editor with the DTD in the
internal subset, and start creating a skeleton by hand (or using the
client's sample as a template: some editors will deduce a minimal DTD
or Schema from a sample document). It's usually fairly clear early on
where the bells and whistles will be needed, so by the time I'm done
skeletalizing, I switch to RelaxNG to build the test model, and make
whatever is needed from that (DTD or Schema). Then it enters the build
and test cycle, and iterates until it fulfils the spec.

[quoted text, click to view]

..NET wasn't really designed for designing XML document structures,
only for processing them. Almost every consultant and document type
designer I know has their own toolkit of applications and utilities
they have picked up over the years, regardless of the platform they
are currently developing for. Generally it makes more sense to do
the initial development on a platform-agnostic basis, and bind it
to an API later on, because if you bind it too tight too early, sure
as hell someone will come and ask you to move the goalposts in mid-
cycle.

[quoted text, click to view]

All of the above :-) Modulo what I said above about using RelaxNG
for document type design, but that's a personal preference. The golden
rule holds, though -- get the data model right to start with, and the
rest pretty much falls into place: get the data model wrong to start
with, and the project is doomed before you even start.

///Peter
--
XML FAQ: http://xml.silmaril.ie/