[uf-discuss] Standardised list of plural properties

[Tantek Ç elik]

On 11/4/05 11:35 AM, "Stephen Downes" <stephen at downes.ca> wrote:

> Tantek Çelik wrote:
> 
>> But we are not starting from scratch, hCard is modeling the vCard schema
>> (including restrictions) ...
>> 
> 
> In general, while it is useful and productive to inherit functionality,
> it is much less useful and functional to inherit restrictions.

Hi Stephen,

You're right in the general case.

When we re-use parts of other specifications to design/specify/build
microformats, it's much more useful to inherit the property names, the
functionality, than the restrictions per se.

As part of the microformats design process[1], we also study existing
content publication behavior, and see whether or not multiple instances of
properties are used or not.

Since the design of microformats is based on existing behaviors, and one of
the explicit principles is to be "as simple as possible", one of the ways of
achieving this simplicity is to specify limitations and restrictions.

Because such limitations are based on existing behavior, the point is that
"in practice" the limitations will not be a problem.

On the contrary, such limitations are *essential* to keeping
*implementations* as simple as possible, which provides the obvious benefit
of a lower barrier to entry, i.e. it is much easier (costs less time/code)
to code a user interface or parser or internal representation to handle one
instance of something than a collection of somethings.

Thus our bias is towards less features, more restrictions, unless there is
supporting evidence/experience to expand.

This is one way we keep microformats simpler and smaller.

Another way to look at this is that we explicitly label "generalization" an
anti-pattern to be avoided, for while generalizing something often provides
the illusion of flexibility, it actually provides significant additional
implementation/interoperability costs, not to mention deeper threads of
theoretical discussion/argument.

Yet another way to think of this is an application of the principle of "lazy
generalization"[2] to data format design.

We keep a microformat as simple and restricted as possible initially, and
then only if/when there is a demand/need to expand/extend/generalize, then
do we generalize, and then only iteratively in response to actual use,
rather than a priori for perceived need(s).


In the specific case of hCard, one additional primary goal is
interoperability with the millions (billions?) of deployed vCard clients.
Thus we have been *very* diligent about inheriting features and restrictions
from vCard as-is.

The restrictions are (for the most part) inseparable from the functionality,
as the functionality derives from the high interoperability of vCard, which
works well because vCard consumers know what to expect based on
features/restrictions and what to support/test, and content authors (and
authoring tools) know what content will be supported.


> Specifications should be directed toward what people are allowed to do
> (or able to do), not toward what they are not allowed to do.

For folks developing the user interfaces for generating the content, and
perhaps more so, for the folks developing the code to parse the content,
knowing what is valid *and* not valid input is essential.

Thanks,

Tantek

[1] http://microformats.org/wiki/process

[2]
"lazy generalization" as applied to programming and framework design:
 http://bugs.sakaiproject.org/confluence/pages/viewpage.action?pageId=5007

"lazy generalization" as applied to AI reasoning / syntactic analysis:
 http://www.answers.com/topic/case-based-reasoning

The above usage of "lazy generalization" may be the first in reference to
data format design in particular.  If anyone knows of earlier
uses/references, I'd be very interested in order to cite them in the future.