3 ms·

Mad how? PDF is a notoriously bad format to extract data from, but great for visually representing the data to humans. XML is human unfriendly but good for stru

Mad how? PDF is a notoriously bad format to extract data from, but great for visually representing the data to humans. XML is human unfriendly but good for structuring data so that software can read it. Embedding the machine readable XML representation of the data in the PDF ensures that both representations of the data are available always.

btgeekboy 8y ago
I think OP is concerned about conflicting data - the visual representation may not match the XML data.
- leovander 8y ago
  ...the visual representation may not match the XML data Hopefully OP doesn't learn about how his medical history is possibly passed around. https://en.wikipedia.org/wiki/Continuity_of_Care_Document https://en.wikipedia.org/wiki/Continuity_of_Care_Document
- askvictor 8y ago
  Given that it's possible to have javascript in a PDF as well, it wouldn't be too hard to have a bit of code that verifies the XML matches the human-readable version. Or, failing that, some sort of crypto signature to check both to see things haven't been tampered with.
  - josefx 8y ago
    As far as I can tell the standard prohibits PDF files with any dynamic content, including javascript. Also there is no point in embedding the verification code in the PDF if you don't trust its contents.
IshKebab 8y ago
Because it will be easy to accidentally make the invoice say something different to the XML. Imagine a company accepts and pays out invoices via this PDF format...
- josefx 8y ago
  It doesn't sound very safe and the draft I found online only describes various restrictions on the PDF and the expectation that the XML is to be seen as an alternative representation for processing. Nothing to enforce that the contents of both are identical or tamper proof. At best you could claim that an invoice were both don't match is invalid, however that would require manual verification. Meanwhile I write the documentation of my xml configuration files in xsd and convert them to something readable using xslt. One set of data for processing and display everywhere and one less headache about duplicated and badly maintained data.
deleted 8y ago
[deleted]

btgeekboy 8y ago

I think OP is concerned about conflicting data - the visual representation may not match the XML data.

leovander 8y ago
...the visual representation may not match the XML data Hopefully OP doesn't learn about how his medical history is possibly passed around. https://en.wikipedia.org/wiki/Continuity_of_Care_Document https://en.wikipedia.org/wiki/Continuity_of_Care_Document
askvictor 8y ago
Given that it's possible to have javascript in a PDF as well, it wouldn't be too hard to have a bit of code that verifies the XML matches the human-readable version. Or, failing that, some sort of crypto signature to check both to see things haven't been tampered with.
- josefx 8y ago
  As far as I can tell the standard prohibits PDF files with any dynamic content, including javascript. Also there is no point in embedding the verification code in the PDF if you don't trust its contents.

IshKebab 8y ago

Because it will be easy to accidentally make the invoice say something different to the XML. Imagine a company accepts and pays out invoices via this PDF format...

josefx 8y ago
It doesn't sound very safe and the draft I found online only describes various restrictions on the PDF and the expectation that the XML is to be seen as an alternative representation for processing. Nothing to enforce that the contents of both are identical or tamper proof. At best you could claim that an invoice were both don't match is invalid, however that would require manual verification. Meanwhile I write the documentation of my xml configuration files in xsd and convert them to something readable using xslt. One set of data for processing and display everywhere and one less headache about duplicated and badly maintained data.

deleted 8y ago

[deleted]