Space: Apache OpenOffice Community
(https://cwiki.apache.org/confluence/display/OOOUSERS)
Page: Draft -- Apache OpenOffice Consultants Directory
(https://cwiki.apache.org/confluence/display/OOOUSERS/Draft+--+Apache+OpenOffice+Consultants+Directory)
Edited by Rob Weir:
---------------------------------------------------------------------
Proposed disclaimer on page:
{quote}
\\
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
{quote}
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:
{code}
<?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>j...@jbloggsllc.com</email>
<phone>123-456-7890</phone>
</consultant>
</consultants>
{code}
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
Change your notification preferences:
https://cwiki.apache.org/confluence/users/viewnotifications.action
