[David Brodbeck]
It sounds like if SPF is going to use XML, there needs to be
defined an XML subset that all records have to adhere to.
But of course, then it's not really XML anymore.
Yes it is still XML. It's XML with a defined schema document. There are
literally millions of XML document types & schemas in wide use today,
the most popular probably being XHTML (which is XML that is HTML 4
compliant, used by a growing number of websites).
The nice thing about XML is that you can have your schema allow for
extensions, but require rigidity in other parts of the document.
See http://www.w3.org/XML/Schema
This "schema thing" is one of the major benefits of using XML for data
interchange: a standard XML parser can handle all your incoming data,
and validate that the input is well formed (according to the defined DTD
or schema), without any custom coding on your part. The programmer still
has to write code based on what the elements and attributes returned
*mean*, but at least they don't have to handle the validation and
parsing of the files themselves. They simply get a nice object tree back
from the parser.
So, for example, I can use a publicly-available purchase order schema,
and send my P.O.s to my vendors. If my vendors accept XML, and I use a
well-known public schema, they can just pump the data into their
systems. This data can be relational and hierarchical, which is more
difficult when exchanging flat text files, as it requires multiple files
and some sort of "data dictionary" too. Also, I don't have to write or
configure a text exporter for each vendor's different text-file format,
and they don't have to write a customized import routine for me.
Anyway, I think the majority of people who oppose XML on this list do so
because the parsing part for SPFv1 syntax is fairly easy because the
syntax is simple; it's the logic that you need after parsing that is the
difficult part. That difficult part has to be done no matter what, they
say, so why use XML which requires more resources?
I personally believe the parsing part of the problem will become ever
more difficult in the future if we use SPFv1-style syntax, as SPFv5 will
someday allow for digital signatures, location-based rules, etc. Someday
we'll have another hacked-together SMTP+MIME-style mess that everyone
will want to replace.
But not many people agree with me, and I'm not involved in the core of
the project, or with writing any implementations. So maybe my opinion is
biased towards intellectually neat and tidy solutions with a hotter new
technology (XML), because I'm not one of the people doing the hard work
of getting SPF implemented.
Regards,
Ryan