namespaces-inconsistency-issue

From Microformats Wiki
(Redirected from namespaces-inconsistency)
Jump to navigation Jump to search

Clean-up needed

The very existence of this page, and the confusion in the below text re-affirms that anything to do with namespaces is confusing, and for the most part, a waste of time. For more on why this is a waste of time, see the namespaces page. - Tantek 15:15, 14 August 2009 (UTC)

to-do: This page should be processed into a set of discrete individual issues on a page like namespaces-issues. This will enable better handling (through FAQs, changes to wiki text, etc.). - Tantek 15:15, 14 August 2009 (UTC)

Introduction

This page outlines a disputed inconsistency that the Microformat's community (note: nearly all of the below was authored by Manu Sporny, one person, and thus it is not representative of "the Microformat's (sic) 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.

Brief Definitions

Here are the widely accepted definitions for context, scope, namespace, fully qualified namespace, and emulated namespace:

context
A context is an enclosing structure that provides semantic meaning to the elements that it encloses.
scope
A scope is an enclosing context where values and expressions are associated. The term is interchangeable with context.
namespace
A namespace is a named scope/context.
fully qualified namespace
Fully qualified namespaces remove all ambiguity from a name. An example of a fully qualified namespace is: http://purl.org/dc/elements/1.1/creator, which is a fully qualified namespace for the Dublin Core property named 'creator'. In C++ std::string is an example of a fully qualified namespace.
emulated namespace
A namespace can be emulated by using an identifer naming convention. For example, png_create_write_struct, png_get_signature, png_read_row, png_set_invalid are examples of C functions that use an emulated namespace called 'png'.

Required Changes

These are the changes that would need to be made to the namespaces page to bring the Microformats definition of a namespace in line with the commonly cited definition of a namespace.

  • The five brief definitions on context, scope, namespace, fully qualified namespace, and emulated namespace should be included on the page.
  • Citations to more detailed definitions from reputable sources should be included on the page, the list of literature at the end of this page would be a good starting point.
  • It should be made clear that Microformats use context, scope, namespaces as a general concept, and emulated namespaces in certain situations.
  • It should be made clear that Microformats do not use fully qualified namespaces for class names, data, or any other Microformatted content.

Logic

Microformats Use Context, Scope and Namespaces

The following is an example of pure context and pure scope:

Example 1: 

var A;
{
   var B;
   {
      var C;
   }
   // at this point, A and B are accessible in this context/scope, but C is not.
}

The example above demonstrates what a pure context and a pure scope look like. The curly-braces are what denote the change in scope from one scope to the next. For example, the variable named C only exists in the inner-most scope.

The following is an example of namespaces (a namespace is a named scope):

Example 2: 

var A;
NAMESPACE_X {
   var B;
   NAMESPACE_Y {
      var C;
   }
   // at this point, A and B are accessible in this context/scope, but C is not.
}

The only change from Example 1, is that now we've named each scope - when you name a scope, it is called a namespace. There are two namespaces defined in this example, NAMESPACE_X and NAMESPACE_Y.

Example 2 can be extended to HTML quite easily:

Example 3: 

<div>
   <span>Manu Sporny</span>
</div>

The example above is similar to Example 2, but it uses HTML markup. The

and tags are what denote the change in scope. The SPAN element is in the DIV namespace in this example.

Example 4: 

<div class="vcard">
   <span class="fn">Manu Sporny</span>
</div>

The example above now has two top-level named scopes that are defined, the DIV namespace and a new namespace called "vcard" - the currently active Microformat namespace. A named scope is a namespace, thus - Microformats use context/scope and namespaces.

Microformats Use Emulated Namespaces

An emulated namespace is a named scope that uses the same prefix to denote semantic similarity. An example of an emulated namespace is:

Example 6: 

png_create_write_struct
png_get_signature
png_read_row
png_set_invalid

The example above uses "png" as the emulated namespace identifier.

Microformats use emulated namespaces in hAtom:

Example 7: 

entry-title
entry-content
entry-summary

The example above uses "entry" as the emulated namespace identifier. The claim that "entry" is a namespace is contested by the primary editor of hAtom. However, "If it quacks like a duck, walks like a duck, and looks like a duck - it's a duck."

Microformats as overlapping trees

Microformats attempt to use a single vocabulary. Therefore, properties like URL, have one definition across all formats, it makes little sense to have hcard:url, hreview:url, hcalendar:url, etc. They all mean the same thing, therefore there is no reason to group them, scope them or namespace them. If you think of each format as a tree structure mapped onto HTML elements, some portions of various trees will overlap and share branches. Scoping and namespacing would prevent these things from happening, but they occur in microformats all the time.

If an hCard is within an hCalendar, all shared properties (i.e. URL) are mixed between both formats. These are the points at which the trees overlap. This was done by design. It does create some limitation, but these where not great enough to out weight the benefits to publishers.

  • The "overlapping trees" model causes problems when (in the above example) there are two, different URLs:


<a href="example.com/johndoe">John Doe</a> 
would like to invite you to 
<a href="example.net/widget-event">a meeting about widgets</a> on...




If John Doe is marked up as an hCard and as the event's organiser (both perfectly reasonable actions), his URL will become the URL for the event, whereas the latter should be used. Such overlaps could be dealt with by parsing rules, but these would be many and convoluted, and may be counter-productive where the URL is shared. This has already been an issue for me, on live pages. Andy Mabbett 02:42, 6 Feb 2008 (PST)


Microformats Do Not Use Fully Qualified Namespaces


There is agreement on Microformats not using fully qualified namespaces. For example, this is verboten:

Example 8:



<div xmlns:vc="http://microformats.org/wiki/vcard-namespace#" class="vc:vcard">
   <span class="vc:fn">Manu Sporny</span>
</div>



The above example uses a QName to specify a fully qualified namespace for the FN class in the VCARD container. This is confusing for beginners, and difficult to author. The difficulty in understanding fully qualified namespaces, and the difficulty in authoring fully qualified namespaces are the primary reasons that fully qualified namespaces are not used in Microformats.



Definitions


Here are excerpts from the definitions and links to further definitions supporting the arguments listed on this page.

The general definition of context is:





Discourse that surrounds a language unit and helps to determine its interpretation.




--- Wordnet: context


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.




--- Wikipedia: scope


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)...




--- Wikipedia: namespace


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.




--- Wikipedia: Namespace (computer science)


The Computer Science definition of an "emulated namespace" is:





In programming languages that do not provide language support for namespaces, namespaces can be emulated to some extent by using an identifier naming convention. For example, C libraries such as Libpng often use a fixed prefix for all functions and variables that are part of their exposed interface. Libpng exposes identifiers such as:


  • png_create_write_struct
    • 

  • png_get_signature
    • 

  • png_read_row
    • 

  • png_set_invalid


This gives reasonable assurance that the identifiers are unique and can therefore be used in larger programs without fear of identifier naming collisions.




--- Wikipedia: Namespace emulation


The Computer Science definition of a "fully qualified namespace" is:





In computer programming, a fully qualified name is an unambiguous name that specifies which object, function, or variable a call refers to absolutely. To fully-qualify most often means to explicitly refer to namespaces that would otherwise be implicit because of the scope of the call.





--- Wikipedia:fully qualified name


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 discussed and FN was 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 then turning around and inconsistently 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.



Sympathetic to the Cause


Below is a list of people that would like the namespace inconsistency more directly addressed by implementing the changes listed above in the "Required Changes" section.




Known anti-pattern


Below is a list of people who believe the namespace anti-pattern has already been adequately addressed in namespaces.



  • hober 11:44, 5 Feb 2008 (PST)


Resolution


Danny Ayers resolves pretty much all of the above regarding "namespaces" in his email:

http://microformats.org/discuss/mail/microformats-new/2008-February/001438.html

This resolution is being contested by Manu since none of the namespaces pages were updated as a result of the discussion. ManuSporny 19:45, 4 Feb 2008 (PST)



References


References that support the commonly understood definition of namespace:



  • Wikipedia:namespace
    • 

  • Wikipedia:Scope
    • 

  • Wordnet:context
    • 

  • History of Programming Languages II, By Thomas J. Bergin, Richard G. Gibson, p.265
    • 

  • Programming and Problem Solving with C++, By Nell B. Dale, Chip Weems, p.369
    • 

  • Computer-Aided Verification '90: Proceedings of a DIMACS Workshop, June 18-21, 1990. p.571
    • 

  • Handbook of Object Technology By Saba Zamir, p.15








Retrieved from "http://microformats.org/wiki/index.php?title=namespaces-inconsistency-issue&oldid=40212"