Re: header syntax.

On Sat, Nov 24, 2012 at 1:06 PM, Pablo Olmos de Aguilera C.
<pablo@glatelier.org> wrote:

> Then after almost a week I don't understand what is a "profile".

I'll take a swing at answering that, since it's a definition I
researched about 3 years ago.

Given a specification A, a profile is a subset (B) of  the
supersetting A specification. In effect, a sub-specification to which
implementers can claim conformance. A superset specification can have
multiple subsetting profiles, optimally layered so that each profile
incorporates by reference all profiles with a smaller feature set in a
linear fashion until the full specification is reached. Hence the need
to begin by identifying and specifying a "core" profile and working
our way outward to a full specification. And by logical extension,
once the full specification is supersetted, it becomes a profile of
the new superset specification.

Profiles are essential to interoperability. Assume for a moment that
we were dealing with the OpenDocument Formats ("ODF") rather than
Markdown. Google Docs and Zoho Writer do not support the full feature
set supported by OpenOffice.org. They are lightweight editors. But
there is no lightweight editor profile of ODF. Hence Docs and Writer
can send documents to be processed by OOo without fear of markup loss
but documents created with OOo cannot be processed by Docs and Writer
without concern for data loss.

But consider the difference if ODF had a lightweight editor profile
and a conformance requirement that a conformant implementation of a
superset profile specification must process subset profile content as
if it were the superset profile content. Then if Docs and Writer
conformed to the lightweight editor profile, documents could be
round-tripped between them and OOo without fear of markup loss.

And were OOo equipped with the means to select which profile the
document is to be written  to and by selecting a mode that makes
features unavailable not supported by the lightweight editor profile,
OOo users could originate documents to be shared with Docs and Writer
without concern for markup loss. For example, in OOo open a new HTML
document and notice that the GUI changes to make unavailable features
not supported by HTML. The same could be done for new lightweight
editor profile documents.

So in my view, the goal of defining a core profile is to identify the
minimum feature set to which all Markdown implementations must conform
to claim conformance to that profile. That does not, however, rule out
supporting more features that are defined in an intermediate profile
or are application-defined. It simply means that a conformant
implementation must be capable of processing Markdown documents as
defined by the core profile, unless we add some sort of metadata to
indicate that a document conforms to the core profile, which seems to
be a non-starter given the Markdown goal of legibility as a plain text
document.

Paul

Received on Sunday, 25 November 2012 01:09:46 UTC