Re-usable content, back to the basics, and knowing your tools
3 min read
I've been on this kick lately of looking at the original architects of the web and what people were doing at that time. This picked up steam in January, 2013, right after our Open Content Authoring Day at EduCon when we started looking at the needed structure to support flexible open content authoring. This led to looking at the origin of REST; the functionality is available in the HTTP standard, but over time we (meaning a lot of people doing web development) just ignored it because of imperfect implementations and assuming everything was HTML, and (un)fortunately things have mostly worked.
There are some issues with how people currently imagine web apps because we:
- Bolted on a lot of "features" that broke or hid the underlying methods and protocols;
- We assumed everything was HTML;
- And as a result created content with embedded markup.
As we move forward, we should think about HTML, JSON, etc. as delivery types not working types. That is, HTML and JSON are presentation issues, not editorial issues. This is the initial thought process we need when working with chunks. I say initial because we will likely expand and include methods or techniques to apply some structure around disparate chunks, but that is secondary to creating re-usable chunks and requires additional structure that is not intrinsic to the content itself. Concentrating on an API first should help us, and reviewing the original intent of the architects regarding REST APIs can provide insight into working with the tools we have rather than things working despite the tools we have.
This article, from 1997, has a lot of good thought around content, structure, and related issues. Fortunately, the transpublishing issues mentioned in the article are not as relevant to work with open content.
This piece, from 1999 (and again from Ted Nelson), defines the roots of some of the problems we have yet to shake. The more things change, the more they stay the same.
Except, unfortunately, some things that should never change often do - like URLs. In 1998 Tim Berners Lee explained that Cool URIs don't change. He even explains content negotiation, which can be used to help manage URIs and avoid exposing implementation details.
In order to progress we need to review our assumptions. As a trivial example when we see things like; 'page.html', 'page.php', or 'page.asp' show up in URLs we have to stop and think "why are we exposing implementation details?"
These problems are tricky to solve and some would argue all abstractions are leaky, and thus any implementation is going to expose some level of implementation detail. Regardless of whether or not that view is reflective of reality, each level of implementation detail that we do expose limits our choices for changing our implementation in the future.
As we move forward with the development of a better open content authoring platform, the mistakes of the past and present are close by. Architectural habits, and exposed implementations became an unquestioned part of system design. This is to the detriment of software getting built, and to the detriment of the people working with the software. Getting back to the basics avoids making the same mistakes.
