The current rev of the specification includes a <prop> element which,
like the element of the same name in TMX, is intended to carry unstructured,
proprietary data along with the "pure" XLIFF data.
I see <prop> as a potentially serious threat to interoperability.
Catch-all hooks like this invite vendors to embrace and extend
standards rather than conform to them or work to collaboratively enrich
them.
By way of comparision, I'd like to point out that the TMX
implementation notes advise that "it's the responsibility of each tool
provider to provide the types and values of the properties it uses."
To my knowledge, no tool provider has actually followed this advice.
Hence, people who want to implement fully interoperable readers are at
the mercy of vendors who want to keep switching costs high.
I propose that we drop <prop> from the XLIFF specification. If an
application needs to communicate data that isn't satsified by XLIFF,
then it can either do it outside of the XLIFF "band" or we can agree to
enhance XLIFF to everone's benefit.
On a technical note, apps that want to do this out-of-band work in-line
can do so much more effectively with namespaces + schemas (though not
DTDs). With namespaces the out-of-band message can be structured and
validated (through XML schemas) as such; conversely, <prop> cannot
contain XML markup without first escaping it.
Eric