Quote:
Originally Posted by Solitaire1
eschwartz wrote the following as part of a post:
My understanding is that XHTML is simply an HTML document formatted as a valid XML document. Due to that, XHTML has none of the formatting fuzziness that is tolerated in HTML.
|
Quote:
Originally Posted by eschwartz
Yes, that is true.
Or to put it another way, it is an XML document defined by the HTML schema.
|
Yes--and
the essential part of this is,
it's XML that carries its schema with it. For all intents and purposes, that is.
Instead of having an XML file with a schema that is
not carried with it, but is, instead, divined by the individual device, based on the user's desires,
the schema (the CSS, effectively) travels therewith.
Sarmat89's issue, by and large (to distill it) is that a formatter can call this:
"Copyright 1989"
Anything that s/he wants. It will, generally, be a <p> code, carrying a CSS styling command. If the formatter is experienced and knows what they're doing, s/he will call it ".copyright" as the class name. This does two things: makes it easy to troubleshoot when things go wrong, and it shows that the formatter is thinking about
structure, as well as appearance.
Sarmat89, however, wants this formatted as its own element. So that it would be (let's say) <copyright>. An element, like a paragraph. And, generally speaking, for very experienced bookmakers of the e-variety, that's not really difficult to do. It would be time-consuming, compared to using p, as there would be a
ton of elements to memorize. I know some bookmakers that do use XML and then parse it with an XSLT sheet to create an ePUB. But what Sarmat wants is for everyone to be forced to use XML, primarily, it seems, because he wishes to be able to see various things--by and large, metadata--that isn't being displayed or used or available, now, in ePUB.
A change like this would, fundamentally, change bookmaking for eBooks. Sarmat89 will say that it won't; but it shall. He'll say that you can make books in XML and then convert them using an XSLT to create ePUBs or (insert book format name here). BUT, he's talking out of both sides of his mouth, because he also asserts that formatting books this way will also allow the user to change how it's seen. To tell his device to display an epigraph this way and a newspaper column that way; to show the Chapter heads left-aligned, for example, as opposed to the center-aligned styling intended by the bookmaker.
Thus, we have cognitive dissonance. Either we're discussing
- bookmakers outputting pure XML files, which would allow the users to style them however they want, using their own XSLT sheets (defaults, presumably, that would be installed on the devices),
- or, we're discussing using XML, to then be converted with XSLT sheets, to create the very same eBook formats that already exist.
And, in either event--neither guarantees that a bookmaker or publisher will complete all the metadata as Sarmat89 desires. As eschwartz pointed out, repeatedly, you can't make a bookmaker NOT type "aaaaaaa" in any textual field.
Thus, this merry-go-round continues to turn, turn, turn turn. To every season turn, turn, turn...ooops, sorry, showing my age there for a moment. ;-) Thus, we seem to be going in rather endless circles.
Offered solely FWIW.
Hitch