Various people (I don't want to critique people, just arguments) wrote:
That's been precluded by the static header of the record. It's not
possible to do this with MARID/SenderID.
and
Nope! It's a locked-down subset of XML.
and
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.
Now I've done plenty of XML work (and I'm generally a fan - the
trading system I designed has now traded over $15 trillion of swaps in
FpML) but I'll admit I'm no Schema expert (I'm just glad that
something is replacing DTDs, I was hoping for Relax NG myself). But
the point I was making is that XML includes all sorts of extras that
we'd be trying to exclude or would have no use for, the external
entities was one obvious example, xi includes are another, I'm sure
someone can come up with a few more. The schemas and the like are
great for specifying what tags are present in what order and nesting
and with what attributes, but they don't define a subset of the XML
grammar, they just specify a vocabulary for the data. So I still have
to use a standard parser that parses the entire record and THEN
validates against the grammar (every parser I've seen first reads and
checks the XML for being well-formed, so must understand ALL the XML
low level grammar and THEN starts the validation against a schema or
whatever).
And if using fixed headers can really exclude those 2 examples BEFORE
parsing, great, but if I'm using a standard parser (part of the XML
argument) then I've still got all that code on my server, just waiting
to be exploited. And I'm trying to validate records against a schema.
This is not the quick and simple operation of a hand parser of a
simple grammar like SPF1, it's a heavyweight process.
And as for extensibility, do I keep the fixed headers and the
validation schema local (in which case bang goes my
'extensibility-without-updates' argument - I'll need to update these
for new versions), or am I pulling it from an external site (and
there's that remote file fetching activities again) ?
XML is a general scheme that relies on general purpose parsers. That
generality costs. For all the slagging off of those of us who oppose
XML in SPF as 'not having any real arguments', I'm yet to hear one XML
advocate admit that parsing XML is always going to be bigger, slower
and more expensive than a hand parser of a specialised grammar, or to
point out where the general nature of XML is needed in SPF (vague
hand-waving about 'in the future' just doesn't count).
I'm failing to remember the pithy quote about using general purpose
software, but my general rule is that closer a component is to the
core heart or essence of a product, the more likely it should be
custom built to do precisely what you need how you need it - use
commodity or outsourced tools for the general purpose non-essential
parts, but specialise the mission critical bits. Most people use XML
at the import and export ends of their systems where it makes sense,
but internally you don't always want or need that degree of
generality. And the TXT record is the heart of SPF (note that an XML
grammar and tool that parsed that and reported the matching SPF
grammar would suit me fine).
XML is being introduced for political and marketecture reasons only.
Not because it has any technical benefits in this arena. And there is
a price to pay for it - anyone expecting XML to be a free-lunch
win-win no-brainer is deluding themselves.
Cheers
--
Tim