AOL ModuleT: A Module Transport Microformat Profile

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.

License

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.

Authors

Shawn Carnell
Joe Dzikiewicz
Kevin Lawver
Paul Maneesilasan

Profile

id

Page Structure

module-name

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.

Linked Objects

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.

manifest: The CSS file for stying the manifest. This can be either an author-created, or the default manifest css file.
tools: Some tools may be provided for module creators that don't need to be replicated across
defaultstyles: Some default styling for pages or modules may be provided.

class

Meta Data

Information about the module and module author.

description

A short, user-readable (ie: not overly technical) description of the module and what it does.

detail

A more detailed description of a module capabilities and requirements.

version

The version of this module.

thumbnail

An <img> element that contains the "thumbnail" image of the module.

author

A block that contains the author's hcard. The element with the class "author" should also have the class "vcard". See the hcard spec for more info. The required elements from the hcard are:

fn: Author's Full Name
email: Contact e-mail address.
url: Homepage URL.

Here's an example hcard:

<ul>
     <li>
          <a class="mailto:kplawver@aol.com">Kevin Lawver</a>
           - <a class="lawver.net">Homepage</a>
     </li>
</ul>

Module Properties

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).

These properties should be contained in a XOXO list. For an example, please see the static module example or skeleton.

module-properties: This class should be attached to the definition list containing the properties. Since it's a XOXO list, the class attribute on that list should be xoxo module-properties.
allow-multiple: Should be used if the user is allowed to add multiple copies of this module on their page. By default, it should be assumed that modules may only have one instance per page.
liquid: The module should expand to fill all usable space (ie: it has no set width). Default is true.
default-width: The default width, in pixels.
minimum-width: The minimum width, in pixels, the module will fit in.

Module Instances

Each module should contain the same basic markup skeleton, this is contained within the block with the id of module.

Container Blocks

module

The containing block for the module. This block should contain all the other information about the module, including the view, and should have the id defined in module-name.

edit

A container for the modules "edit" interface, if it has one. Modules may just be content, but other may require information like a URI in order to work properly. This profile doesn't try to define how the module and edit interface work together or are connected. Any element with this class must also contain module-name.

view

A container for the "view" of this module. This is the piece displayed to the end user. Any element with this class must also contain module-name

module-name

This should be the same value defined for the module-name id.

This class has multiple uses and locations:

linked stylesheets: Since all 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
view: Because you'll need to consistently style a module even when it's embedded in another page, it should have a unique class on it along with "view".
edit: Same reasoning as "view"

Within Containers: Module Pieces

head: The heading of a module. If your module doesn't have a title or any heading information, it's not required. This should also be a <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.
body: This is the "meat" of the module. Can contain any markup, but it shouldn't reuse the "module", "head" or "body" classes. This class must be within one of the containers: edit or module.
foot: A footer for a module. Must always be within one of the containers: edit or module.

rel

Module Information

documentation: Should be used on a link that provides documentation for the module, although most documentation should be contained within the detail section.
license: A link to the license for this module.
proxy: Specifies an url that the module importer will need to proxy for the module to be able to use AJAX. The interface of how to do this inside a module is still being worked on.

Examples

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).

Static Content - The simplest possible module. Just content.
Module Skeleton - Just because we're nice, a barebones skeleton so you can go create your own module.

Related searches:
module should element required default

gipoco.com is neither affiliated with the authors of this page or responsible
for its contents. This is a safe-cache copy of the original web site.

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.