|
@Toxaris:
What is your impression, are those integration problems caused by proprietary applications and their questionable data formats or by the lack of tools that would translate and interact between XML formats if it were in XML? At least for publishing, there are huge advantages in XML-based workflows, and it is widely used in various ways. What kind of formats are increasing in application integration, binary ones with corresponding APIs to access them?
@eschwartz:
I frequently run into people who have problems with Calibre EPUB files (with reading them or using them for online services), and a portion of those problems are due to the lack of standard conformance, which is absolutely avoidable, but forces users to fix those errors while they usually don't know how. I myself develop processing tools which convert to EPUB, especially to build automated workflows based upon semantic markup. I won't produce invalid output, I'll refuse invalid input, I'll support front ends which are compliant to the various standards (so all conversions in the workflow from the first character typed to the printed hardcover book will be executed over well-defined interfaces). I don't support EPUB2 input yet, and I don't have a problem with <u> since I don't use Calibre (the issue wasn't initially posted by me). However, if file editors are sloppy with their output, a lot of files need to be manually adjusted in the future or are less usable as they could be because visual appearance was encoded instead of meaning.
A developer of EPUB2 or XHTML 1.1 processing or reading software would not only be expected to support all elements that are specified by the standards, but also to react on the old crappy legacy stuff like <marquee> etc. This bloats code for no use at all, and if the task is to just do some primitive transformations, it is far better to ignore all the old, deprecated non-standard constructs which shouldn't be there anyway.
|