Warning: This message is a little long. It presents how XmlMindXmlEditor
helped me solve a use case and also suggests one small improvement.
Background: SGML-based HTML allow(ed) us to create (and validate) HTML
fragments. E.g. the following document, if you paste it into the W3C’s
SGML-based validator,[1] will validate (not as an "official" and full
HTML4 document, but it will validate as that what it is: a document
where blockuote is the root element):
<!DOCTYPE blockquote
SYSTEM "http://www.w3.org/TR/html4/strict.dtd";>
<blockquote><h1>Quote of today:</h1>
<p>To be or not to be,</p></blockquote>
But as anyone who has tried to "join" HTML and XHTML knows, the above
document looks quite different from how (text/html) Web browsers would
actually do with the document when they parse it: A Web browser wrap the
full HTML DOM, with <html>, <head>, <body> elements and so on, around
the <blockquote> element. Which is, mostly, all right, as long as it
only happens in the Web browser.
The problem, though, is that not only Web browsers are affected -
authors/HTML editors are typically affected too. E.g. if you open the
above document in as DOM-based editors like BlueGriffon, then it would
convert the document to a full HTML document. And it is a general thing
that editors inserts things that they thinks belong there.
XmlMindXmlEditor does similar things too - not for the same reasons as
BlueGriffon but still.
This causes a problem: You are responsible for a collection of Web pages
- such as a Web site - and you would like to hand over responsibility of
creating maintaining certaint fragments, only, to someone else. You do
not want to let that other person edit the entire page - you only want
him or her to edit that «Quote of today» section. Also, you do not
want to have to 'dig out' the useful fragment from a document that
contains lots of unnecessary stuff. You want the fragment to be ready to
be inserted once it has been edited.
**Solution? XHTML to the resque- In tandemn with XmlMindXmlEditor.** The
following document is opened and edited fine by XmlMindXmlEditor:
<blockquote xmlns="http://www.w3.org/1999/xhtml";>
<h1>Quote of the day</h1>
<p>To be or not to be</p>
</blockquote>
What does the trick is a) the omission of the DOCTYPE (which makes sure
that nothing is validated) and b) the addition of the XHTML namespace to
the blockquote element. If you save that document with .xht or .xhtml,
then it even renders with the default HTML styles if you preview the
fragment in a XHTML-capable Web browser - the namespace does the trick
for them too.
However, there is still one thing going on in XmlMindXmlEditor: The
auto-insertion of the XML declaration. Fortunanaly, this can be fixed to
by configuring the XMLmind XML editor’s save options.[2] (My HTML
generatior is file based, in that it just inserts the content of the
file - it does not look for particular fragments within the file - and,
let’s face it, many tools works like that ...) In fact, for our
situation, the "site generator" that I use had an issue with importing
non-ASCII - so I even told XmlMindXmlEditor to convert non-ASCII to
numeric character references:
<cfg:saveOptions
saveCharsAsEntityRefs="true"
charsSavedAsEntityRefs="160:65535"
omitXMLDeclaration="true" >
</cfg:saveOptions>
In my case, the motivation for starting all this was to be able to edit
fragments in a tool that a non-technical co-worker can use:
XmlMindXmlEditor. I also wanted what the co-worker produced to be ready
to be inserted into the HTML generator - there should be no need to
perform any extra conversion after the fragment had been edited. The
HTML generator in question would point to the "fragment file" and insert
its content into the respecive page that it is linked to.
Now, the observant reader might think that, hey, the namespace
declaration is not valid when inserted into a HTML file. And you would
be correct, if we spoke about HTML4 or XHTML1.x. But as for HTML5, the
XHTML namespace declaration is permitted ony any element, so there is no
actual need of removing it.
The close-reading reader might think about how such a fragment could be
useful even in a 100% XmlMindXmlEditor workflow. For example, by use of
XmlMindXmlEditor’s XInclude support, the fragment could be included in
another document that XmlMindXmlEditor controlled. And via XInclude and
XmlMindXmlEditor, it is even possible to include one fragment into
another fragment!
* **Feature request:** My only gripple/grapple/issue in that regard is
that, when both the main/mother document and the included/child document
are 'fragments', then XmlMindXmlEditor does not permit to preview such
the compound document. Perhaps that could be made possible?
* **Feature request:** It would also be nice if it was possible, via the
File->New menu to create a 'fragment document'. As it is, one must
create the fragment in a text editor, save it and then open it in
XmlMindXmlEditor - it is really only a small, even tiny issue. But still
- could be worth fixing.
My final words are that I am very happy that I finally found a quite
practical way to solve the ’fragment document editing issue’ - I
have looked for a solution for years (why aren’t there more solutions
for this?), and ... I am very happy that XML Mind XML Editor provided
the solution!
[1] http://validator.w3.org/check
[1]
http://www.xmlmind.com/xmleditor/_distrib/doc/configure/saveOptions.html
--
Leif Halvard Silli
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
