Difference between revisions of "minimal-vocabulary"

From Microformats Wiki
minimal-vocabulary
Jump to navigation Jump to search
(drafted)
 
(→‎benefits: emphasize new)
Line 7: Line 7:
 
Minimizing the vocabulary used for properties (and values) of a microformat helps make and keep microformats easier to understand.
 
Minimizing the vocabulary used for properties (and values) of a microformat helps make and keep microformats easier to understand.
  
Minimizing the introduction of new vocabulary is particularly important. Doing so:
+
Minimizing the introduction of ''new'' vocabulary is particularly important. Doing so:
 
* Keeps microformats as a whole easier to understand (the smaller the total vocabulary of all microformats).
 
* Keeps microformats as a whole easier to understand (the smaller the total vocabulary of all microformats).
* Reduces confusion with the re-use of existing technologies.  
+
* Reduces confusion with the re-use of existing technologies.
  
 
== preserve literal vocabulary when reusing meaning ==
 
== preserve literal vocabulary when reusing meaning ==

Revision as of 21:03, 1 June 2009

<entry-title>minimal vocabulary</entry-title> One aspect of the start as simple as possible microformats principles, and one of several Naming Principles.

One way of keeping a solution simple is to minimize the vocabulary that the solution uses, and certainly of those, minimize any new vocabulary that are introduced.

benefits

Minimizing the vocabulary used for properties (and values) of a microformat helps make and keep microformats easier to understand.

Minimizing the introduction of new vocabulary is particularly important. Doing so:

  • Keeps microformats as a whole easier to understand (the smaller the total vocabulary of all microformats).
  • Reduces confusion with the re-use of existing technologies.

preserve literal vocabulary when reusing meaning

When reusing the schema or meaning from an existing format, when possible re-use the respective vocabulary as well.

This particularly important to illustrate, given how often the opposite has occurred (unnecessary renaming/tweaking/abbreviating of existing terms), over and over:

Example org

hCard 1.0 deliberately re-uses the literal org property name from vCard specifications.

On the other hand, the following apparently simple / intended to be helpful renamings have been found:

Example organization name

hCard 1.0 also deliberately re-uses organization-name from vCard specifications per the semantic-xhtml-design-principles.

The unfortunate "clean-up" efforts:

avoid the Anglo centric anti pattern

All of these renamings/expansions/abbreviations may seem (semi-)obvious to English-centric readers, but cause unnecessary confusion when a non-native-English developer encounters different terms that mean the same thing from vCard to these other technologies.

To a non-native-English developer, "org" and "affiliation" are two different sequences of characters, and look as different as "bet" and "nssvyvngvba" do to a non-native-ROT13 developer.

The unnecessary English renaming of English word properties from earlier standards is an Anglo-centric (specifically English-speaking designer) design mistake that needs to be more thoroughly written up as a design anti-pattern to be avoided.

more examples

see also