[uf-discuss] hAtom draft - utility of feeds

[Benjamin Carlyle]

On Wed, 2005-12-28 at 17:10 -0500, David Janes -- BlogMatrix wrote:
> I notice that Tantek has placed a generic opaque container as a 
> potential idea onto the blog. If multiple feeds per page is OK with all 
> and a generic opaque container is available, then we get it "for free".

I'll try to share some of my thinking on the opacity question:

Opacity is required when:
1. There is a uf element that I think I understand, but may have a
definition that differs from mine.
2. There is a uf element that I think I understand, but it may not apply
to my context. It may apply to a context that I do not recognise and
have skipped over.

Opacity (identified nesting generally, in fact) could be about solving
the problem of applying context to complete a triple, or about providing
a walled garden over which common definitions do not apply, or about
both. Microformats already make use of nesting that can only be
understood if you are a parser of that microformat, and annotates each
nested level with at least one type (vcard, vcalendar, etc).

I have a quick mapping of the potential solution space:

== Different Definitions, aka naming the type ==

1.1 Do not permit different definitions of the same term

1.1.1 Hold old microformat definitions valid until they pass out of
common use
	+ Definitions are stable, new versions of old ufs are not created
	- The set of terms may become more esoteric than necessary when the
most widely-understood usage of a term is barred in favour of an older
and less widely-understood one

1.1.2 Review the validity of old definitions from time to time and widen
or replace them with more appropriate definitions
	+/- inverse of keeping definitions valid
Possible mitigating strategies:
	* Start with esoteric names such as vcard-title rather than title, or
reviewer rather than author (of a review). Move to more mainstream names
only when it is proven across several microformats to be
widely-understood. Parsers accept both esoteric and mainstream names
until esoteric ones pass out of common use.

1.2 Permit different definitions. Opacity is required to avoid tripping
over elements that appear to signify something they do not.
	- Opacity is no longer a matter of completing the triple using context.
It is also a boundary of understanding. What can you rely on? title?
author? vcard? It may be important to specify which definitions are
fixed, and which movable.
	- Without a boundary of understanding in place users would be able to
define arbirary contexts to allow author, contributor, and the like to
be applied to individual documents. This might not directly affect
parsing. Consider the atom "entry" concept. It may not have to exist if
it were always clear what an atom author applied to. Likewise, one might
mark up a hreview of hcard in the hAtom style. All that would be needed
would be to add "mfo" to a div and insert further metadata relating to
that div.
	- Harder to use css?

== Different Contexts, aka completing the triple ==

2.1 Define global ruleset for context

2.1.1 Applies to parent context (mfo) but not children of that context
	+/-?

2.1.2 Applies to parent context and child mfos
	+ Good for author, contributor

2.1.3 Applies only to child mfos of the element
	+/-?

2.2 Define a per-element ruleset for context
	+ Allow author to be defined differently to ???

2.3 Allow individual element instances to identify context
	+ Allow the whole triple to be defined in one place, "foo is author of
bar"
	- More complicated... triples don't seem to match human prose well.

Back to the subject of hAtom, I think the terminology issue has to come
to a head if forward momentum is to be maintained. It would be nice to
get a resolution to that as early as possible in the mfo process. Will
there be divergence in definitions? If not, who will budge? What should
the strategy be going forwards? I think this will rely on the people
involved getting as face-to-face as possible for a few hours at some
point :)

-- 
Benjamin Carlyle <benjamincarlyle at optusnet.com.au>