Re: XmlConfigFile usage

"Brian Candler" <[e-mail]> schrieb im Newsbeitrag
news:[e-mail]...
> > http://www.pault.com/pault/pxml/xmlalternatives.html

Btw: I couldn't access this site (no DNS). Has anybody experienced the
same?

> Not really "being displeased", but XML is a language for marking up text,
> and doesn't by default have semantics for doing data-handling jobs (like
> storing config files or serialising objects).

I'd say this is at least not 100% true.  XML application is typically
distinguished as "document centric" and "data centric". The first is the
markup category while the second focuses on representing tree structures.
An XML document is data centric, if an XML element either contains PCDATA
OR other elements, but not mixed content.

> You can't say "I'll just
> serialise this object to XML using xxxlibrary" and expect it to
interoperate
> with another platform; you'll be able to _parse_ it anywhere, but you'll
end
> up writing code to interpret the structure.

.... unless you use some tools to do that for you.  Typically configuration
information is interpreted, too - so this might not be too much of a
disadvantage for XML in this case.

> Also, some of those XML 'alternatives' are just different syntax for the
> same thing, i.e. using indentation instead of <tag>...</tag>
>
> > YAXML isn't so easy in the eyes, either.
>
> It doesn't look too bad to me. At least, a hash expands to
>     <key1>value1</key1>
>     <key2>value2</key2>
> which is how you'd instinctively design an XML schema to do that. But I
> haven't found an implementation to try.

Personally I would model an XML schema for a hash different. This would
look like
<Hash>
  <Entry>
    <Key>key1</Key>
    <Value>val1</Value>
  </Entry>
  ...
</Hash>

or

<Hash>
  <Entry key="key1">val1</Entry>
  ...
</Hash>

But I would definitely not name the elements after the key.  It's a bit
more verbose but IMHO this reflects the data modeling better and it lends
itself better for automated processing.

Kind regards

    robert