The need to syndicate distinct pieces of content and functionality has led to several complex XML schemas and web services. We feel they're all too complex for the "average" developer to create. We need something simpler, that will lead to a larger adoption by the internet at large, not just CMS developers. This is our attempt at doing that.
This is a first draft, and there are still a lot of open questions about module interaction and what toolset will be provided for more complex modules. How those tools are released, hosted and shared across everyone who may want to import and display modules, among other issues are still up in the air. Feedback is welcome.
There are pieces of this microformat that are required, which isn't strictly specified in
XMDP. In all browsers that
support CSS, required sections should be red. In browsers that support the :after
pseudo-selector, you should see the word "required" in parentheses after the
title of that section and/or property. Unless otherwise specified, each element is optional.
All required elements have a class of "required" on their dt.
Please send feedback to modulet-discuss-at-listserv.aol.com. If you would like to join the list and join in the discussion about the format, please send an e-mail to listserv@listserv.aol.com with subscribe modulet-discuss in both the subject and body of the e-mail.
Use of the Publisher Module Specification is governed by the Specification Copyright and Patent Licenses. Please review these licenses now. By using the specification you are agreeing to their terms and conditions.
The element with the class module should have an id that is the concatenated module name. If your module was named "Foo Bar's Module", the module-name would be "foo-bars-module".
For example, if you're creating an HTML document that has one module on it, and that's all the page has on it, you could use the module-name id on the body element. But, if you were building a gallery of modules, you could put the id on an element that contains that module's information.
Module may be dynamic. In the event that modules will need to include their own CSS or
Javascript files, they should be in the head of the document. Any script or CSS file in
the head should be imported into the importing document unless they contain one of
the following id's. It is still up for discussion if module importers should ignore any
<script> or <link> elements with
id's.
Information about the module and module author.
<img> element that contains the "thumbnail" image of the
module.Each module has some properties to express what kind of module it is, and some of the rules for displaying it. This list is certainly not complete yet. You can use multiple classes within the body element to declare multiple properties for the module. This section will grow over time as we receive feedback (and we're OK with that).
This section will probably morph into something that falls inline with the existing XOXO microformat for defining key:value pairs with definition lists.
Each module should contain the same basic markup skeleton, this is contained within the block with the id of module.
This should be the same value defined for the module-name id.
This class has multiple uses and locations:
link elements must be in the document head, we
need a way to link stylesheets to their module. So, all stylesheets associated with
a module must have the class <div>,
and if it contains heading text, it should be contained in an
<h3>. This class must be within one of the containers: edit
or module.Modules can and should support tagging. It's not required, but the more data about a module, the better, right?
Instead of putting a code example here that we know we'll never update, here are some "live" examples of modules someone might create. They don't exercise every piece of the format, but you get the idea (hopefully).