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
