I still have to review all the emails that have been pouring in, but
this one struck me. We should clarify something before things get too
far along.
By putting the [type] in <x class="citation [type]"> we are hiding data,
this something that microformats strive to avoid. A simple solution
would be to bring the [type] value out into visible data.
<x class="citation">
<x class="type">(enumerated list of possible types here)</x>
<!-- you could also achieve a similar effect with the ABBR element -->
<abbr class="type" title="(enumerated list of possible types
here)">Free Text here!</abbr>
...
</x>
i'll try to comb through all the emails so far and draft a sort of synopsis.
Another thing that really helped some hCalendar discussion was to plan
an IRC meet-up, We all selected a time when we could meet online and
knocked-out several of issues at once. Would folks be up for that? if so
i can get a sort of agenda together about loose ends and coordinate a time.
let me know,
-brian
Alf Eaton wrote:
> OK, so a minimal microformat for a citation could look like this:
>
> <x class="citation [type]">
> <x class="title">Item title</x>
> <x class="creators"><hcards></x>
> <x class="container citation [type]"><hcitation for the
> container></x>
> <x class="pages">n-n</x> [and anything else specific to this
> particular type of citation]
> </x>
>
> I think that's essentially very similar to Mike's version too.
>
> alf.
>
> On 29 Mar 2006, at 14:20, Breton Slivka wrote:
>
>> True, but a mechanism for this sort of thing already exists for
>> microformats in XMDP, and in a somewhat more flexiible form, in that
>> one does not need a monolithic profile for all the modules involved,
>> one can have a seperate profile for each module and link to each
>> seperately.
>>
>> The basic thrust of this is to follow the microformat principal of
>> solving the simple problem first. Out of all these specific domains
>> exists a definite "simplest problem". The only dispute that I see is
>> that the simplest problem doesn't solve all the domain specific
>> problems. You wouldn't expect it to! So you make additional
>> microformats to solve the domain specific issues. Thus the "micro" in
>> microformats, as I understand it.
>>
>> On Mar 29, 2006, at 12:13 PM, Alf Eaton wrote:
>>
>>> On 29 Mar 2006, at 14:02, Breton Slivka wrote:
>>>
>>>> If we are for the moment to entertain the idea of modularization,
>>>> couldn't type then be simply inferred by which module(s) in use? If
>>>> you go with a nesting microformat model for that, type is
>>>> encapsulated entirely in the container class of specific modules,
>>>> and the modules which are in use determine behavior, much the same
>>>> as embedded svg/mathml does today, or a more direct comparison in
>>>> the modularization of xhtml.
>>>
>>> If you embed MathML and SVG in XHTML you still have to use the right
>>> DOCTYPE, so that the validator knows which modules are allowed
>>> (though admittedly you don't necessarily need the precise DOCTYPE
>>> just for displaying/interpreting the document):
>>>
>>> <!DOCTYPE html PUBLIC
>>> "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN"
>>> "http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd";>
>>>
>>> alf.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> microformats-discuss mailing list
>>> microformats-discuss@microformats.org
>>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>> _______________________________________________
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
