namespaces-inconsistency-issue

Introduction

This page outlines a disputed inconsistency that the Microformat's community has had for a number of years. Namely, in the way the community defines "namespace" and the position it takes against that definition of a namespace.

History

In June of 2007, while discussing what should be the name of a song, album or audio recording for hAudio, it was suggested that TITLE be re-used from hCard. This kicked off a debate about whether it would be appropriate to re-use TITLE because TITLE was previously defined in hCard as "job title". Manu pointed out that this was not the proper English definition for TITLE, would confuse authors, and inquired as to why TITLE was defined in such a constrained way. It was shown that TITLE re-used the definition of TITLE from the VCARD specification, and since TITLE had been set as such, re-defining it to become in-line with the English definition of TITLE would have ramifications on hCard implementations out in the field.

A suitable replacement for TITLE was mentioned by Scott Reynen and adopted for hAudio.

Several months later, Martin McEvoy raised the issue again - that FN is not a suitable replacement for the title of an audio recording. Manu argued that TITLE should be brought in line with the English definition once again, and another argument about namespacing started on the microformats-new mailing list. This discussion revolved around an assertion that Manu was making about Microformat's having a stance against namespacing, but using "emulated namespaces" as a replacement when there was no other option but to namespace (such as in hAtom - "entry-title", "entry-summary", "entry-description")

Manu asserted further that the community has an inconsistent stance on namespaces because the community's definition of namespacing was not standard. It deviated from the definition in the field of linguistics, programming language design, and mainstream computer science literature. To illustrate the point, it was shown what the standard definition of 'namespace' is using a number of text books on the subject.

Manu is currently challenging the vague and inconsistent definition of namespace that is being used in the Microformats community and is asking for further refinement on the types of namespaces that are and are not allowed in the Microformats community.

Definitions

The general definition of namespace is defined as:

...a namespace is an abstract container providing context for the items (names, or 
technical terms, or words) it holds and allowing disambiguation of items having the 
same name (residing in different namespaces)...

The Computer Science definition of namespace is:

A namespace is an abstract container or environment created to hold a logical grouping 
of unique identifiers (i.e., names). An identifier defined in a namespace is associated 
with that namespace. The same identifier can be independently defined in multiple 
namespaces. That is, the meaning associated with an identifier defined in one namespace 
may or may not have the same meaning as the same identifier defined in another namespace. 
Languages that support namespaces specify the rules that determine which namespace an 
identifier (i.e., not its definition) belongs.

The definition of scope is:

In computer programming, scope is an enclosing context where values and expressions are 
associated. Various programming languages have various types of scopes. The type of scope 
determines what kind of entities it can contain and how it affects them -- or semantics. 
Scopes can:

    * contain declarations or definitions of identifiers;
    * contain statements and/or expressions which define an executable algorithm or part 
      thereof;
    * nest or be nested.

A namespace is a scope that uses the enclosing nature of the scope to group logically 
related identifiers under a single identifier. Thus, scopes can affect the name resolution 
for their contents.