tools for document interoperability
This is the web diary for nfoWorks and realization of the Harmony Principles. Pursuing Harmony tracks nfoWorks research, analysis, specification, and implementation of tools for document interoperability. There is commentary on related activities that address conformance, interoperability, and harmonization of document formats.
The nfoCentrale Blog Conclave
nfoCentrale Associated Sites
Technorati Tags: open source, open formats, interoperability, open development, OpenDocument Format, ODF-OOXML Harmonization, ODF
I have no appraisal of the relative maturity and quality of the various toolkits that are emerging on the ODF scene (and likewise with regard to OOXML). However, it is important to have a cataloging of what there is. This is a random start. I will add to this post and build an nfoWorks catalog page later:
An important resource for ways to harmonize document formats involves attention to the libraries and models employed for constructing document-centric software and their applications. This applies for the development of testing and conformance tools as well as for implementation of format-supporting software products. Indeed, one might reasonably expect that such tools would be a companion demonstration of implementation-support quality.
In the interesting case of OpenDocument Format, the availability of open-source code bases for implementations is both a risk (in that deviations or omissions in support for the standards
For ODF, the continuing work on toolkits and on independent open-source implementations is providing important diversity. This can inform the search for a harmonious profile and perhaps suggest adaptations that encourage harmonious implementations. Diversity across platforms and programming models may also help in the recognition and abstraction of essentials away from implementation incidentals. That can also be valuable in ensuring that harmonization is on essentials and not accidents of implementation.
I will be reviewing available toolkits, libraries, and APIs as I define my own around interface contracts for abstracted levels of document models and processing support. I expect some cross-fertilization while adhering to a model that is concentrated on harmony.
Technorati Tags: ODF-OOXML Harmonization, OpenDocument Format, interoperability, conformance, testing, validation, verification, open standards
It is sponsored by a neutral (ODF-supporting) organization. It is attended by major implementers of ODF-supporting products, including IBM, Microsoft, and Sun Microsystems.
In short, all of the right people are in the same room, some for the first time, and I am so envious that I am not among them. There should be a great deal of creative tension.
I will be watching for materials and progress reports. There is already Doug Mahugh’s useful pre-event post on how Microsoft tested the ODF implementation in Office 2007 SP2 to ensure that it only produced standard-conforming documents and failed in ways that did not introduce security exploits against the Office System or documents of its users.
I have been meaning to post more about my involvement with ODF and how it is fueled by my interest in the harmonious level at which we can start and expand interoperability based around standard, open formats for office-productivity applications. I will do that separately. For now, I just want to register my excitement for the positive stage that participation at this meeting represents.
[Update 2009-06-16-18:56Z There are little odds and ends available from the ODF Plugfest so far, and I will compile some links here for safe-keeping. I am sure there will be additional blog posts and reports by more attendees after they have had some time for reflection]
[Update 2009-06-17-17:11Z with a few more straggling in]
[Update 2009-06-18-17:51Z as other posts show up]
[Update 2009-06-23-14:55Z with some stragglers]
[Update 2009-06-24-18:55Z and one more interesting appraisal]
[Update 2009-06-27-21:40Z and the hits keep on coming …]
[Update 2009-07-01-15:25Z wrapping up, with anything more on plugfests in future posts]
Here are some apple-orange notions that have come to my attention in an oddly-convergent way.
New OASIS Technical Committee IPR Mode
OASIS has just announced the pending addition of a 4th IPR Mode to the set that technical committees can use as the way intellectual property (mainly essential claims of patents) will be made available to adopters of a TC-produced specification:
The ODF TC operates under the RF on Limited Terms Mode, the most-generous mode available until now. As stated under the OASIS IPR Policy, a TC may not change its IPR Mode without closing and submitting a new charter. I don’t expect such a shut-down and restart to happen, especially before ODF 1.2 becomes a ratified OASIS Standard.
Many will welcome this new mode. I know that my willingness to participate in OASIS Technical Committee activities increases exponentially as we move down the list. The RF on Limited Terms and the new Non-Assertion modes are the only ones that I have no hesitation about.
The Non-Assertion Mode is comparable to everyone obligated by the IPR mode having automatically made an equivalent of the Microsoft Open-Specification Promise with regard to the specifications produced by the TC during their participation.
Of course contributors, participants, and anyone else can provide non-assertion covenants with regard to any specification, as Sun Microsystems did for ODF in September, 2005.
Implementation License Models and Interoperability
The licenses under OASIS IPR modes apply to implementations of the applicable specifications, such as ODF.
I have recently been dealing with provisions of the ODF specification that do not seem to be understandable on their own, not even by consulting referenced source materials. In that case, there is no way to ensure interoperability without consulting an implementation or two. In complex cases (such as figuring out how to decrypt an ODF document that is encrypted using the approach sketched in the ODF specification), it is actually necessary to inspect code to determine what the missing but essential details might be. (It would be better to find implementation descriptions that explain how the specification is being satisfied, but too often the code is the only reliable implementation description.)
When the code is available in an open-source implementation, it may be possible to reverse-engineer an implementation-independent interoperable interpretation. That is what I would look for, assuming that I could master such code well enough to resolve questions the specification leaves open.
Consulting code works for detective work around clarification and hole-filling of the specification. If I want to make an implementation based on that interpretation, I must be especially careful about the license on that code. For example, LGPL and GPL code and other reciprocal-license open-source software is not useful to me in producing software under a license that I prefer (Open BSD, Apache, etc.). I am cautious about digging around in voluminous code anyhow, but I am particularly wary about risking that I might copy GPL code.
In this case, I am reluctant to rely too strongly on an abstracted interpretation unless the specification itself is updated and issued with an interpretation I can then safely rely on.
In effect, specifications that are sufficient for implementation-independent achievement of interoperability, along with royalty-free licenses or covenants, provide the ultimate clean-room support for achievement of unencumbered independent implementations.
That’s what I’m after.
Technorati Tags: open government, open government data, open principles, open formats, open documents, open data
It strikes me how much simpler and well-framed this discussion is, contrasted with the over-stated manifesto for document freedom.
Somehow, when it is about simply-described affirmative principles, it becomes simpler to grasp and to imagine the possibilities and opportunities that are afforded. Here are the key qualities around public government data public made open:
with reviewable compliance.
There is more to be found on the wiki, and anyone can register and add their questions and perspective to the fleshing-out of these notions.
One can splice open documents, especially the public’s documents, into this structure as well. This puts important context around the technological issues involved in having documents in formats that everyone can use and that are freely implementable in computer software.
This has me think of a few other qualities that might matter in both domains, especially around durability/permanence.
You might have some thoughts about this too. Visit the Open Government Working Group page for more.
Today’s celebration has the over-the-top theme: “global day for document liberation.” The thesis is that
A Little Less Manifesto Please
I fancy the simpler notion of promoting “document formats that can be used by everyone and safely implemented in free software.”
I must also caution that the existence of such a format does not assure that my computer-maintained documents will be able to survive intact beyond the availability of the specific software that I use to create and present them. There is no causality here, as much as we would like there to be. There is, on the face of it, a greater opportunity, but not necessarily one that I can exploit on my own.
Owning My Own Documents
Having said that, here’s what document freedom means to me:
That would satisfy me that I am truly the owner of my computer-supported documents.
It takes more to satisfy me that the choice of different platforms and products is a minor concern and there are reliable substitutes. That would require that the level of interoperable use among (versions of) document-processing products be so high that faithful interchange of our documents and even successful roundtrip collaboration in their development and refinement are assured.
Too Slippery the Slope
I think that is worth striving for. I don’t think we are close yet. I don’t think any of the sloganeering and posturing is doing anything to accomplish it. There are too many mixed agendas:
The Public’s Documents in Public Formats
There needs to be some serious reality-based assessment and measurability. That’s what it takes to be secure in the ownership of my documents. That’s what it will take to be sure that those documents that are the instruments of our civil society are indeed the public’s documents, using the public’s formats.
The lingering question, one to ask on next year’s Document Freedom Day, and then the year after that, and …, is who are the stakeholders and what action will they take to substitute reality for blind flag-following?
[update 2009-03-26T01:06Z: I should simply go to Rick Jelliffe’s blog before I open up my mouth about anything to do with open formats. If I could ever find the blankety-blank RSS feed I would be so much happier. Meanwhile, here are some relevant words on the status quo and the sow’s ear:
Technorati Tags: Cover Pages, W3C, multimodal architecture, MMI, multimodal interfaces, document behavior, document content, interoperability
[update 2008-11-06 I don’t know how I failed to see that the very first sentence didn’t carry the sense I intended for it.]
A current weakness in the open-document standards arena is the poorly-specified and tacit coupling of format provisions to behavior in various document processing contexts (creation, viewing, editing/manipulation, and various “final-form” renderings and, these days, interactive performance governed by the document, whether slide-show or something more elaborate).
We’ll get to that some day, and the ways that such aspects are layered into specifications and their allowance for application innovation and conformance novelty remain to be discovered.
This Cover Pages Daily Newslink item from 2008-10-21 leads to an account of the W3C Technical Report on Multimodal Architecture and Interfaces Fifth Working Draft.
I’m putting down an nfoWorks marker because of these intriguing passages in the Newslink:
I am hesitant about the following:
There are some wise words about keeping straight the different design-time and run-time considerations.
I suspect that this is not going to bear directly on realization of the Harmony Principles, but it might provide useful conceptual underpinnings for an account of the behavioral aspects that are at least as important in document-mediated interoperability as the standard document format.
From the Cover Pages: XML Daily Newslink for 2008-10-14, there is announcement that the OASIS Darwin Information Typing Architecture (DITA) Technical Committee has formed a new subcommittee. The DITA for Technical Standards Subcommittee has the ambitious purpose of furthering and promoting DITA use for the creation, maintenance, and support of technical standards specifications. The idea is to have a “common standard for the creation and publication of … technical standards specifications:”
I’m not sure that this has any near-term benefit, but it does arouse my interest in another way. I am finding it very difficult to wrap my head around the current and in-progress OpenDocument Format (ODF) and Office Open XML (OOXML) specifications. I need some way to wrestle out my understanding in a way that allows me to surface a conceptualization of the functions of either in a way that their reconciliation at the Harmony Principles level can be grasped and described in some useful way.
DITA surfaces on my radar from time to time. It is something I think I should know more about. I don’t know how to apply it in the context of standard document formats, nor am I clear how it is applicable to the conceptualization and expression of document-format standards. It does strike me that some help is needed, based on my early efforts in the analysis of ODF specifications. (At this point, concept-mapping software might be even more useful, and I will look into that as well.)
It is time to dig deeper into DITA to see how it can support a harmonization effort with regard to office document formats and their harmonizable specification.
Technorati Tags: text-to-speech, W3C, Harmony Principles, interoperability, document rendering, document accessibility
Via the Cover Pages: XML Daily Newslink for 2008-10-14, I learn that the W3C has standards for speech-enabled/-enabling web applications. The addition announced today is the W3C Pronunciation Lexicon Specification (PLS) Standard. This is an accessibility as well as a convenience feature. PLS is intended to work with Text to Speech (TTS) and VoiceXML applications.
The PLS lexicon is an XML document and there is allowance for blended use with other namespaces. This suggests to me that there is prospective use in interchange of office-productivity documents for various purposes.
I don’t expect that this will fit into any foreseeable level of harmonized features. I am placing this marker because it may well feature in accessibility provisions at some point, even if accomplished via a public-profile agreement involving foreign elements.
The accessibility angle is an important one to keep an eye on for its interoperability, interchange, and preservation potential.
Technorati Tags: interoperability, IE8, web site construction, web standards, compatibility, conformance, document preservation, document formats
Be prepared for a dramatic shift in the reality of web-site browsing and the honoring of web-page standards. The pending release of Microsoft Internet Explorer 8 is going to put the reality of web standards and their loose adherence in our faces. Although Internet Explorer is indicted as the archetypical contributor to disharmony on the web, Internet Explorer 8 is going to challenge all of us to deal with the reality of our mutual contribution to the current state of affairs.
Here is a lesson, probably many lessons, for document interoperability and the way that standards for document formats evolve and harmonize, or not, over time.
The Web as Clinical Science
The movement from loosely-standard pages and their browsing to strictly-standard pages and standards-mode browsing will illustrate every aspect of the same challenge for office-productivity documents and the office suites that process them.
Web pages are the experimental drosophilae of digital documents. All aspects of dynamic convergence on standards, themselves evolving, and the forces of divergence, are demonstrated clearly and rapidly. I expect it to take Internet generations for significant convergence, with no static level of standards adherence anywhere in sight. It took us almost 20 years to get to this point on the Web; I figure it will take at least five more to dig out of it far enough to claim that there is a standards-based web in existence and in practice. I'm optimistic, considering that HTML 5, the great stabilization, is not expected to achieve W3C Recommendation status until 2012.
No document-interoperability convergence effort is anywhere close to the promising situation of the web as Internet Explorer 8, HTML5 implementations, and other compatibility-savvy browsers roll out over the next several years. It is useful to use that situation to calibrate how convergence and interoperability could work for document interoperability. There are significant technical barriers. The non-technical barriers are the most daunting. That should be no surprise.
Versioning in Document Use
I've written on Orcmid's Lair about the IE 8.0 Disruption. This involves changes in Internet Explorer 8.0 by which web pages are rendered in standards-mode on the assumption that pages are conformant with applicable web standards. In the past, it was presumed that pages were loosely-standard and browsers, also loosely-standard, made a kind of best effort to present the page. The consequences have been explained marvelously in Joel Spolski's post on Martian Headsets.
We are similarly relying on document-format standards as a way to provide for many-to-many interchange and interoperability between different (implementations of versions of) document-format standards and different (implementations of versions of) processors of those digital documents. That means we have a version of the loosely-standard documents with loosely-standard processing problem. We can't be strictly standard because the standards can't (and definitely don't) have strict implementations at the moment; and there are many ways that specifications and implementations have been kept loose by design. Accompanying that looseness by design is the the simple fact of immaturity among the contending document-format standards for office applications, particularly as vehicles for interoperable applications.
For office-productivity documents as we know and love them, there are five, count 'em five "official standards."
The "Official" Public Standards of Office Documents
For Office Open XML Format (OOXML), there is the ECMA-376 specification of December 2006. There is also the ISO/IEC 29500:2008 Office Open XML File Formats standard once it is made available. IS 29500 will have some substantive differences from ECMA-376. We won't have a solid calibration of the differences until the IS 29500 specifications are available and subject to extensive review.
For the OpenDocument Format, there is the Open Document Format for Office Applications (OpenDocument) v1.0 OASIS Standard issued 1 May 2005. There is also the ISO/IEC 26300:2006 Open Document For Office Applications (OpenDocument) v1.0 standard (also on the publicly-available listing). IS 26300 is for the same format as the OASIS v1.0 standard, but it is on a completely-separate standards progression. Appendix E.3 accounts for the differences of IS 26300 from the text of the May 2005 OASIS Standard. The first page of the IS 26300:2006 document (page 5 of the PDF) identifies its source as Open Document Format for Office Applications (OpenDocument) v1.0 (Second Edition) Committee Specification 1, dated 19 July 2006, derived from document file OpenDocument-v1.0ed2-cs1.odt; this is not another OASIS Standard, however.
The second and latest OASIS Standard for ODF is Open Document Format for Office Applications (OpenDocument) v1.1 issued 2 February 2007. This document is derived from OpenDocument v1.0 (Second Edition) Committee Specification 1, the same specification that is the source of content for ISO/IEC 26300:2006. The changes made to arrive at ODF v1.1 from the v1.0 (Second Edition) committee specification are detailed in Appendix G.4. There are some mildly-breaking changes from ODF v1.0 to ODF v1.1, mostly of a clarification or correction nature. There are a few additional features that have no down-level counterparts in ODF v1.0.
A third OASIS Standard, ODF v1.2, is under development. The current drafts, using a very-different organization from v1.1, are available as pubic documents of the OASIS Open Document TC.
We can expect to see more versions of ODF and of OOXML at their various standards venues. We'll be watching here on nfoWorks as the situation becomes even more chaotic. Notice that this diversity ignores the variety of divergent implementations of the various specifications.
Format Versions that Live Forever
It is possible for one document-format specification to officially supplant another, with the older specification deprecated. That has not been done so far with any of the five-and-growing document-format specifications, any more than it has been done for most of the versions of HTML specifications that have been recommendations of the W3C (and IETF before the development track moved entirely to W3C).
For example, the last full-up specification for HTML, the HTML 4.01 W3C Recommendation of 24 December 1999, has this to say about its immediate predecessor: "This document obsoletes previous versions of HTML 4.0, although W3C will continue to make those specifications and their DTDs available at the W3C Web site." This was possible because HTML 4.0 was young and there were important defects that 4.01 cured.
The HTML 4.01 specification continues with the following recommendation: "W3C recommends that user agents and authors (and in particular, authoring tools) produce HTML 4.01 documents rather than HTML 4.0 documents. W3C recommends that authors produce HTML 4 documents instead of HTML 3.2 documents. For reasons of backward compatibility, W3C also recommends that tools interpreting HTML 4 continue to support HTML 3.2 [W3C Recommendation 14 January 1997] and HTML 2.0 [IETF rfc1866 November 1995 and the IETF-obsoleting rfc2854 June 2000] as well."
The XHTML branch of specifications, originally derived from HTML 4.01, were intended as the basis for a future generation.
Meanwhile, there has been work toward both XHTML 2 and HTML 5.0.
HTML 5.0 is currently intended to exist alongside XHTML 1.x and its newer arrangements while also absorbing XHTML 1.x to some degree (by having an XML form). The current HTML 5.0 draft specifies legacy processing (in its HTML-syntax form) for variations of over 60 HTML DOCTYPE DTD flavors, extending back to HTML 1.0 and other variants. The intention is to converge HTML and XHTML 1.x under a consistent HTML 5 processing model with only no-quirks, some-quirks, and quirks modes. This is also intended to end the variation and extension of HTML (not XHTML) by capturing <!DOCTYPE HTML> for its own and having a concrete HTML syntax that is fully-divorced from both SGML and XML. It is important to point out that HTML 5 is not going to eliminate the divergence that browser (user-agent) plug-in models, plug-in implementations and scripting systems (especially client side) bring to the mix.
Document-format versions are not easily abandoned. Even if production of a format is deprecated, consumption of the format may need to continue into the indefinite future, and certainly so long as emitters of deprecated formats have significant usage. The W3C progression of HTML is at a point where that is fully-recognized and being honored in reaching toward an HTML 5 plateau sometime in the next decade.
Considering this promising stabilization, when would I manage to change all of my web sites and blogs to clean HTML 5 pages? Not until I know that visits to those sites are only a small fraction of Internet Explorer versions prior to IE8 (or maybe IE9) and other browsers lacking full-up standards-mode processing. Fortunately, the HTML 5 specification-effort promises to show me exactly how to do that in a mechanical way. I am looking forward to automated assistance. In my case, I'll also have the benefit of my IE 8.0 mitigation effort. Other web sites may require other approaches, and user browser choice will involve important trade-offs for some time.
I am surprised by the number of people who operate multiple browsers. Although I operate multiple products for office applications these days, that's mostly to explore their interoperable use, not to ensure ability to interchange documents (well, not until I joined OASIS and the ODF TC). I've been a serial adopter of Internet Explorer versions since IE 2.0. As a typical late-adopter, I may finally branch out now just to have a better calibration of the migration to standards-based sites and browsers for them.
This is an important lesson for the management of the expanding variety of specifications of formats for office-application documents, formats of which HTML packagings are sometimes one of the flavors.
Reconciling office-application document-format versions does not promise to be so easy as the current effort to stabilize HTML for the web.
The Looseness of Document Specifications
Of course, OOXML and ODF are not close dialects off a single family tree, as HTML variants might be treated (and HTML 5 demonstrates, if successful). In addition, the current specifications are not for same-conformance, interchangeable-everywhere documents:
Prospects for Interoperable Convergence
We already have before us difficulties with interoperable convergence of individual progression of a single standard and its variety of implementation. This makes the prospect of harmonization between different standard formats rather murky.
Desktop office-application software has more promise with regard to application of Postel's Law, to be liberal in what is accepted and conservative in what is produced. Unfortunately, the current specifications do not require conservative, interoperable implementations; the current specifications are arguably antagonistic to such an achievement.
I suspect that this is an unintended consequence mixed with some inattention to what it takes for interoperability to be achievable.
It remains to see how our experience and understanding matures. We are at the beginning, not the finish. The journey may seem endless.
The process of IE 8.0 mitigation and preparation for a standards-mode approach to web browsing impacts this site and blog as well as every other web page I have ever posted (somewhere over 120MB worth and climbing).
I'm not going to say anything more about IE 8.0 mitigation and HTML harmonization here. The overall effort will be tracked in that category of Professor von Clueless posts; that's the place to follow along. The lesson for document interoperability is something that is definitely appropriate for Pursuing Harmony; there'll be much more to say about that.
Technorati Tags: interoperability, document formats, document processing, Harmony Principles, presentation conformance, conformance, ISO/IEC 24754
One problem for harmonization of document-format implementations in the case of ODF and OOXML is the degree to which those specifications may provide inadequate specification of how documents are to be presented in order for implementations to be adequately interoperable. This situation arises between implementations of the same format as well as between different document formats.
Along with establishing clarity on how much agreement in presentation is required, there is the small matter of being able to somehow confirm that an application achieves whatever that level of conformance and interoperability is.
As I suggested in "Interoperable ODF: Finding Ground Truth," there are many difficulties to be conquered in advancing from the current state of affairs to where there is reliable determination that implementations are substitutable in a particular interoperability setting.
We don't have good ways to even talk about the multiple, interlocking problems that lurk beneath the simple desire to have interchange of documents in standard formats "just work."
It would be helpful, for starters, to at least have a way to describe what a particular document-processing system does in rendering documents that it accepts. A checklist on the handling of particular features of an electronic document is also useful in determining conformance and interoperability guidance and, perhaps, eventual mechanical verification criteria.
The XML Daily Newslink for 2008-08-18 reports on a contribution that may be useful in this regard, the "First Edition of ISO/IEC 24754: Minimum Requirements for Specifying Document Rendering Systems." From the scope:
The Final Committee Draft (omitting the example in the informative appendix) is available as a 7-page, 74 kB PDF file.
Beside the announcement, here's what attracted my attention:
Technorati Tags: Jesper Lund Stocholm, ODF, OpenDocument Format, Microsoft Office 2007, Document Interoperability Initiative
Jesper Lund Stocholm has found his files from the Microsoft Document Interoperability Initiative ODF Workshop. His post, "DII ODF Workshop - the good stuff", shares the nitty-gritty on-the-ground experience of transferring ODF documents from OpenOffice.org to Microsoft's pre-beta Office 2007 SP2 implementation and back again. There's a download of eleven test files, each in two forms, along with PDFs of how they render. There's an OpenOffice.org version of each document. Then there's the Microsoft Office 2007 SP2 pre-beta ODF saving of the same document. This is enough to discern how the the two applications handle application-specific features from other applications and express application-specific features of their own.
There are some great lessons becoming available with regard to interoperable use of document formats. Here's what I see in terms of the Microsoft Office and OpenOffice.org implementations of ODF:
I don't foresee the Harmony Principles alleviating this situation in any way. At best, I expect it to help us appreciate the cost of interoperability and its improvement over time.
This is an initial post for ramping up the Blogger creation of Pursuing Harmony. The blog will replace the manually-created diary that was first used with nfoWorks. This initial page is created to cause population of the blog, its archives, and the RSS feed.
The blog starts out using Jason Sutter's "Sand Dollars" format, one of the supplied Blogger templates. I will customize that to achieve my preferred style once operation of the blog is confirmed.
Customization happens after blog editing and posting is confirmed to be functioning.
My first problem was attempting to use SFTP. I reverted back to plain-old FTP to make sure the FTP log-in could succeed. This wasn't working the same as previously, so I tried a different path name. The problem may have been a lag in set-up of the account that I created for Blogger to use in posting to the web site. After one false-start, it all started working.
1. Update 2008-08-12T21:55Z After succeeding with this initial post, I decided not to use the Blogger NavBar. If I want to add a search panel for searching the blog and/or the site, I will do that later.
On getting Windows Live Writer working with the site, I attempted to establish an upload directory for images included in the blog. LiveWriter reported that it could not confirm the URL. I will make sure the new directory is established and give it a construction structure. I should then be able to have LiveWriter use it.
I am also going to move the archive directory out of the top-level blog directory, so that backup and maintenance is easier.
Live Writer reminded me to add tags to this post, and I will do that now too. I see that the categories work differently and are independent of tags. I must not be so careless in choosing categories.
2. Update 2008-08-12T23:34Z The archive is moved and the image directory was pre-populated with an index.htm so that Live Writer's concern for the folder was removed. It is now time to demonstrate that picture uploading works:
3. Update 2008-08-13T00:03Z After I figured out what time it is here (for adjusting to GMT in these little update items), I also managed to correct the URL for where the images are so that, not only are they uploaded, they are also correctly-reachable from the blog post.
My next effort is to make sure that I have a back-up procedure for mirroring the blog content on my development machine along with the other parts of nfoWorks.
After that has concluded, I will need to start working on the template.
4. Update 2008-08-13T00:12Z Well, the Neighborhood Rose images are on the blog site, but Live Writer fails to notice that I corrected the URL in my FTP settings. So I am linking in the above picture manually. I will introduce an additional image so that it can upload with the new settings.
Now I can introduce the backup procedure and then start adjusting the template.
5. Update 2008-08-13T00:53Z One concern I had is the automatic creation of subfolders to hold images from separate posts. I have verified that no subfolder index is available on the server and there is no way to explore the images but via image elements on the blog pages. That is satisfactory.
6. Update 2008-08-13T20:25Z I have carried out one manual backup. Before taking the customization to the next level, I have made a couple of simple touch-ups.
The next step is to construct the safety net and fire-drill procedure for the blog. It has been some time since a blog has been corrupted, but that is no reason to start operating without a net.
created 2008-08-13-18:06 -0700 (pdt)