- From: marbux <marbux@gmail.com>
- Date: Sat, 24 Nov 2012 17:09:19 -0800
- To: "public-markdown@w3.org List" <public-markdown@w3.org>
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