Before moving from ConceptualModel to SyntaxConsiderations it's worth considering interop with other data models and formats. For Echo to be really useful, interop should be as seamless as possible. If this is considered up front then it won't be necessary to reverse-engineer from the syntax later.
See also :
ExtensionModule (with DefinedDataModel and UniqueIdentifier) Needs Definition, Please.
See also :
BloggerProposals for a SOAP API.
This largely relates to the AtomApi, though there are SyntaxConsiderations too. Blogging and syndication applications can be viewed as web services - how does Echo fit in with other Web Services formats and systems such as XML-RPC, REST, SOAP, WSDL, UDDI, ebXML and DAML-S?
See also :
Among formats of particular relevance are (X)HTML (see EscapedHtmlDiscussion), RSS 1.0 and 2.0 and such things as RVW, and all the other stuff that can come as a Movable Type plugin... Also it would be useful to be able to say something like "this blog entry is about that email post" without having to resort to human longhand. How will Echo interact with Wikis?
See also :
Among models of particular relevance are the Topic Map-style model, as seen in XTM, XFML and ENT and the RDF-style model as seen in RDF, FOAF, RSS 1.0 and OWL. If we had a separate <metadata> element, allowable anywhere, that can contain any valid XML metadata, in the style of SVG, it will cover a lot of the Topic Map/RDF ExtraInterop issues.
In all of these cases it may well be possible to interoperate by pumping the XML serialization through XSLT, but for this to make any sense there has to be a mapping defined at a higher level.
Additionally there may be something to be gained from looking at how the ConceptualModel may be represented in implementation, i.e. a Relational Database model and an Object-Oriented model. See also GeneralizingEntry.
It could just be as simple as saying that e.g. a postID corresponds to a topic id (in XFML), a resource (in RDF) or a primary key (in RDBMS).
[MichalWallace RefactorOk] I have been thinking about a abstract database structure for holding comments, categorization, revisions, and the entries themselves in Rantelope. It's based on predicate logic and at first glance, it seems to be very compatible with the ConceptualModel.
We can have interop at a higher level than pure syntax for no extra effort, and still have the standard XML representation with DTD, XML Schema and Relax NG schema etc. Misunderstandings will be easier to prevent (almost by definition) by working at a semantic rather than syntax level. As far as the benefits go, it doesn't have to be either-or. A whole load of possible work duplication could be avoided - for example, a standard mapping to SQL database tables could also be derived easily from a more abstract model than working from a specific XML syntax. GeorgBauer's point that people that want different representations can use XLST is valid, but I think it would make for a considerably tighter standard going from the top down together, rather than going straight down one narrow track and having people go off side-to-side from there.
Simplicity and popularity of RSS 2.0 gave it a big edge of RSS 1.0. But what it lacked, which RSS 1.0 had, was a framework for systematically working with other models and formats. If this is to be a New Format then might we not be able to take good bits from RSS 1.0 rather than just repackaging RSS 2.0. And no, I don't mean make it RDF/XML - there are many different ways this could be done while still maintaining simplicity.
Tim Bray says you need to specify bits on the wire. Sure. But you need to specify a whole load more than that for it to work with existing systems. How, for example, are things like licenses and copyright to be used with the new format? Use Creative Commons of course. How? Use namespaces of course. But will it be applied per-entry or per-feed? How will the text of the license be linked in?
Note also that in the Related section talk is of typed links, with the typing being defined through namespaces. How can compatibility with 3rd party systems be achieved (even existing ones such as RSS 2.0, TrackBack and the Blogger API) if everything has to be done at the syntax level? There is no guarantee that the typing is expressed in a syntax-compatible fashion.
I certainly agree that the primary syntax should be simple, vanilla XML. I also think that whatever happens it will be essential for Semantic Web compatibility to also provide a standard RDF/OWL mapping (to the RDF model, not RDF/XML).
[StevenGarrity RefactorOk] I wrote a bit a while back about the problem of search engines using the "page" as the base unit of info and weblogs using the "post" (see my original writing on the subject). The result is that Google thinks two posts on the front page of your blog are related, when there might not be - and that the URL for that info is the URL of your front page, which is really isn't (for long). We've gotten around this somewhat by many weblog publishing tools giving each post it's own page, but this doesn't help on the front page). Might it be possible for the Echo format to be in some way embedded into the XHTML of a site (with it's own namespace?) so that Google (and other search engines) know one post from the next. Is this at all within the scope of the Echo project?
[TomasJogin] Don't that problem disappear -- atleast regarding the front page -- when google comes crawling back and the front page has changed; pushed one or all of the previously "related" entries off of it?
[JimDriscoll,RefactorOk, DeleteOk] Embedding - and using its own namespace - would basically require that the Echo output be in XML format - and displaying it would, in all probability, require the registration and general adoption of a new MIME type, text/xhtml+echo or application/xhtml+echo, given the general lack of support for raw, styled XML in browsers. Still, with well-formed XHTML, it would be relatively trivial to wrap each post in an arbitrary (HTML?) element, with some attribute set to indicate that it is an Echo blog (eg <div class='echoBlogv1'>)... the problem being that doing so would be an abuse of HTML. If you really, really, want blog entries to be considered as separate, they'd have to be on separate 'pages', linked in to the main page via <iframe> or preferably <object>. Doing so would also have obvious caching advantages at the expense of increased load time and decreased compatibility. (UPDATE) Looks like much of this is covered in SyntaxConsiderations.
[AsbjornUlsberg, RefactorOk] It's no problem to embed custom tags in XHTML, if you prefix them and declare your own namespace. Though I don't think embedding Echo in XHTML is the solution we're looking for. Every (X)HTML document will have it's own internal structure, and each structure has a different meaning from one another. Some may use <table>-tags for structuring their pages, some may use <div>'s and others may use plain <p>-tags, etc. These different structures are impossible for a machine to understand as the same, so my suggestion is rather to link to alternative representations of the current viewed HTML document (that being a frontpage, an individual article, a short list of articles, or whatever) through <link>-tags in <head>, e.g.:
<head> <link rel="alternative-representation" type="application/not-echo+xml" href="frontpage-echo1.0-2003-07-09T19.22.13.xml" title="Current frontpage Echo 1.0 feed" /> <link rel="alternative-representation" type="text/rss1.0" href="frontpage-rss1.0-2003-07-09T19.22.13.xml" title="Current frontpage RSS 1.0 feed" /> <link rel="alternative-representation" type="text/rss2.0" href="frontpage-rss2.0-2003-07-09T19.22.13.xml" title="Current frontpage RSS 2.0 feed" /> </head>
It will probably be difficult to make this a standard way of referring to alternative representations, but we have to start somewhere, and I think this might work.
CategoryArchitecture, CategoryMetadata, CategoryRss, CategorySyntax