This evening, I realized there’s something wrong with my virtual: protocol handler. It degrades gracefully to real protocols if a virtual file isn’t in the file service, but it doesn’t edit the loaded real file’s links to other files. I can’t point from a real file to a virtual one.

There’s really only two simple solutions to that problem: either have everything a virtual file points to become virtual, or have nothing it points to become virtual. A little thinking makes it obvious you can’t have everything virtual. If I’m editing foo.com, and I link to www.w3.org, the latter is content I don’t have any control over, so that mustn’t be virtual. On the other hand, if nothing’s virtual, you lose a lot of the benefits of having a virtual protocol in the first place; you can’t see the impact of one file on another.

After a little more thinking, I realized a deeper issue, a conceptual one. Specifically, some XML documents link to other files regularly (XUL, XHTML, XBL). But other XML files usually don’t (MathML, SVG, RDF). It’s a big consideration, one that HTML editors never had to think about. HTML is all about hypertext, which fundamentally is about linking.

This morning, I also hit on the thought that most files in a web environment are organized in a hierarchy of directories. This is something that’s obvious to web developers, but it also means an editor should consider hierarchy. You usually have a common point of reference for all files and directories within the hierarchy. This common point is often called the “base URI”.

When I edit web documents or files, I have to deal with one hierarchy in two or more places. There’s a server-side base URI, where the files really live, and a client-side base URI, where I edit my local copies before uploading changes. Plus, if I’m doing any sort of server-side processing of XML, I probably have a staging area where I do tests away from the production website.

So I figure content I control belongs in a repository, with its top being a base URI. That lets me maintain multiple repositories if I want: a virtual one for on-the-fly editing, a local one where the files are directly accessible, a staging repository for testing, and a production repository for the actual files. At the same time, I don’t have to use a repository structure if I’m editing individual files.

When you add it all up, it becomes ultimately an issue of user capabilities and user interface. Users will want the ability to edit stand-alone XML documents, and users will want the ability to edit interdependent XML documents. So the Verbosio back-end core code must be scalable to the repository model, while the front-end user-interface must be able to force a singleton model on the back-end. It doesn’t work any other way.

No, none of this is talking about FTP uploads, CVS or SVN repositories, or any publishing methods. This is strictly about how Verbosio will refer to documents and files it edits

. Publishing, while very important, comes later.

Creating XPCOM interfaces to store the needed information is easy. The hard part is in coming up with an intuitive user interface for matching local files (or directories) to remote locations!