On 10/3/05, Costello, Roger L. <costello@m...> wrote:
>
>>
> The issue is this: what are the roles of an XML document?
>
> As I have been doing with my previous messages, I will make a hypothesis and
> then invite your critique.
> Hypothesis: The Role of an XML Document is either as a Storage Medium or as
> a Transport Format

Maybe I'm missing something, but these questions smell to me like
"given that XML is the hammer, how do I make my data look like a
nail?".

XML as just a particular way of labeling and standardizing *data*.  It
obviously imposes a few constraints  on what kinds of data it can
easily / efficiently handle, but questions about the "role of XML"
seem backwards to me.  Start by thinking about the role of your data
--- is it just the state of an application, is it a master storage
record, is it something that drives a UI, is it information shared by
multiple applications, etc. -- then design it to meet those needs.  If
the needs and the design intersect with XML's tools and use cases, map
the data to XML.  If they don't (as I argued in the original thread,
since the pickers / vineyards scenario cried out for a normalization
and relational storage), don't use XML, or use it only for interchange
scenarios.

There are a lot of interesting (aka "hard") questions relating to the
"map the data to XML" step. Object-XML mapping, Relational-XML
mapping, and classic XML design questions (such as whether to use
elements or attributes, whether the XML ID/IDREF mechanisms are
sufficient to model graphs, how finely to decompose into instances,
etc.) are all still pretty open AFAIK.