View Source

Proposed disclaimer on page:

Although most individual users are able to download and use Apache OpenOffice without any help, or with the assistance of volunteers on our Forums and mailing lists, some users, especially corporate users, may have more complex requirements that require commercial services in order to optimize their deployments. The following individuals and firms offer services that may be of interest. The information provided here was provided by the entities named here, and is not verified or endorsed by the Apache OpenOffice project. We offers this listing as a service to the ecosystem.

Consultants who wish to add their listing here should follow the instructions provided on this page: XXXX

The listing would then be HTML, machine generated by an XLST transform on a XML file we store in SVN. For example, the XML could look like this:

<?xml version="1.0" encoding="UTF-8"?>
<consultants>
    <consultant>
        <name>Joe Bloggs, LLC</name>
        <logo>jbloggs.jpg</logo>
        <discipline>Deployment</discipline>
        <discipline>Migration</discipline>
        <description>Joe Bloggs, LLC provides custom deployment and migration servives for small and medium business moving to OpenOffice.  We work with the client from initial
        evaluation and piloting, through deployment and beyond.  References and whitepaper are available on our website.</description>
        <website>http://www/jbloggsllc.com/openoffice.html</website>
        <email>joe@jbloggsllc.com</email>
        <phone>123-456-7890</phone>
    </consultant>

</consultants>

The schema for this is defined by:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="consultants">
    <xs:complexType>
      <xs:sequence>
        <xs:element maxOccurs="unbounded" ref="consultant"/>
      </xs:sequence>
    </xs:complexType>
</xs:element>

<xs:element name="consultant">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="name"/>
        <xs:element minOccurs="0" ref="logo"/>
        <xs:element maxOccurs="unbounded" ref="discipline"/>
        <xs:element ref="description"/>
        <xs:element ref="website"/>
        <xs:element minOccurs="0" ref="email"/>
        <xs:element minOccurs="0" ref="phone"/>
      </xs:sequence>
    </xs:complexType>
</xs:element>

<xs:element name="name" type="xs:string"/>
<xs:element name="logo" type="xs:anyURI"/>
<xs:element name="discipline" type="discipline"/>
<xs:element name="description" type="description"/>
<xs:element name="website" type="xs:anyURI"/>
<xs:element name="email" type="email-address"/>
<xs:element name="phone" type="xs:string"/>

   <xs:simpleType name="email-address">
    <xs:restriction base="xs:string">
      <xs:pattern value="[^@]@[\.]\..+"/>
    </xs:restriction>
</xs:simpleType>

<xs:simpleType name="description">
    <xs:restriction base="xs:string">
      <xs:minLength value="0"/>
      <xs:maxLength value="300"/>
    </xs:restriction>
</xs:simpleType>

<xs:simpleType name="discipline">
    <xs:restriction base="xs:string">
      <xs:enumeration value="Deployment"/>
      <xs:enumeration value="Migration"/>
      <xs:enumeration value="Extensions"/>
      <xs:enumeration value="Training"/>
      <xs:enumeration value="Customization"/>
      <xs:enumeration value="Other"/>
    </xs:restriction>
</xs:simpleType>

</xs:schema>

Consults could submit or edit their entries via a CMS patch, a Bugzilla issue or via the mailing list.

The HTML that is generated could take advantage of the XSLT capabilities to sort and categorize the data in several ways, e.g., alphabetically by name, categorized by specialty, etc. We could evolve this over time, and as needed, based on the number of entries we receive. For example, at some point, if we have a lot of entries, it might make sense to javascript-enhanced tables, to allow interactive sorting and filtering. The key thing is to have a clean separation of the data from the presentation, so we are free to update the website as our needs grow.

Initially it would probably be a separate build step, i.e., modifying the XML would require a build, via XALAN, to generate the HTML. But a further refinement would be to then integrate that with the CMS so it happens automatically. That should be the goal, but we don't need to get there in one step.

From a policy perspective, we need to be fair in who we list. We should submissions from the broader ecosystem of consultants providing services related to Apache OpenOffice. A proposed list of technical and other requirements is:

Consultant must submit valid/well-formed description in our defined XML format, or equivalent information in text form.
In order to have a good looking website we would have specific logo requirements, perhaps a common size, formats, no animated GIF's.
Description text would have a maximum length. We want to avoid someone putting in page-length descriptions. Description is plain unformatted text, no images, no hyperlinks. In general, from a security perspective we don't want the possibility of any user-submitted active content being promoted to the website.
The listing must not misuse ASF trademarks or be likely to cause confusion with ASF trademarks. This would apply to the entity name, the email address, website domain, website contents, description, etc. This would be our main non-technical filter on submissions