source-git / libxml2

Clone
Source Code
GIT

Blame doc/guidelines.html

c8 c8s master
  1.   571f18a95c6e28341d6b354490af897b00685cf6
  2.   doc
  3.   guidelines.html
Blob History Raw
Packit Service a31ea6
Packit Service a31ea6 
    "http://www.w3.org/TR/html4/loose.dtd">
Packit Service a31ea6 
<html>
Packit Service a31ea6 
<head>
Packit Service a31ea6 
  <meta http-equiv="Content-Type" content="text/html">
Packit Service a31ea6 
  <style type="text/css"></style>
Packit Service a31ea6
Packit Service a31ea6 
TD {font-family: Verdana,Arial,Helvetica}
Packit Service a31ea6 
BODY {font-family: Verdana,Arial,Helvetica; margin-top: 2em; margin-left: 0em; margin-right: 0em}
Packit Service a31ea6 
H1 {font-family: Verdana,Arial,Helvetica}
Packit Service a31ea6 
H2 {font-family: Verdana,Arial,Helvetica}
Packit Service a31ea6 
H3 {font-family: Verdana,Arial,Helvetica}
Packit Service a31ea6 
A:link, A:visited, A:active { text-decoration: underline }
Packit Service a31ea6 
  </style>
Packit Service a31ea6 
-->
Packit Service a31ea6 
  <title>XML resources publication guidelines</title>
Packit Service a31ea6 
</head>
Packit Service a31ea6
Packit Service a31ea6 
<body bgcolor="#fffacd" text="#000000">
Packit Service a31ea6 
XML resources publication guidelines
Packit Service a31ea6
Packit Service a31ea6
Packit Service a31ea6
Packit Service a31ea6 
The goal of this document is to provide a set of guidelines and tips
Packit Service a31ea6 
helping the publication and deployment of
Packit Service a31ea6 
href="http://www.w3.org/XML/">XML resources for the
Packit Service a31ea6 
href="http://www.gnome.org/">GNOME project. However it is not tied to
Packit Service a31ea6 
GNOME and might be helpful more generally. I welcome
Packit Service a31ea6 
href="mailto:veillard@redhat.com">feedback on this document.
Packit Service a31ea6
Packit Service a31ea6 
The intended audience is the software developers who started using XML
Packit Service a31ea6 
for some of the resources of their project, as a storage format, for data
Packit Service a31ea6 
exchange, checking or transformations. There have been an increasing number
Packit Service a31ea6 
of new XML formats defined, but not all steps have been taken, possibly because of
Packit Service a31ea6 
lack of documentation, to truly gain all the benefits of the use of XML.
Packit Service a31ea6 
These guidelines hope to improve the matter and provide a better overview of
Packit Service a31ea6 
the overall XML processing and associated steps needed to deploy it
Packit Service a31ea6 
successfully:
Packit Service a31ea6
Packit Service a31ea6 
Table of contents:
Packit Service a31ea6
    Packit Service a31ea6 
      
  1. Design guidelines
    		2.
    Packit Service a31ea6 
      
  2. Canonical URL
    		3.
    Packit Service a31ea6 
      
  3. Catalog setup
    		4.
    Packit Service a31ea6 
      
  4. Package integration
    		5.
    Packit Service a31ea6
    Packit Service a31ea6
    Packit Service a31ea6 
    Design guidelines
    Packit Service a31ea6
    Packit Service a31ea6 
    This part intends to focus on the format itself of XML. It may  arrive
    Packit Service a31ea6 
    a bit too late since the structure of the document may already be cast in
    Packit Service a31ea6 
    existing and deployed code. Still, here are a few rules which might be helpful
    Packit Service a31ea6 
    when designing a new XML vocabulary or making the revision of an existing
    Packit Service a31ea6 
    format:
    Packit Service a31ea6
    Packit Service a31ea6 
    Reuse existing formats:
    Packit Service a31ea6
    Packit Service a31ea6 
    This may sounds a bit simplistic, but before designing your own format,
    Packit Service a31ea6 
    try to lookup existing XML vocabularies on similar data. Ideally this allows
    Packit Service a31ea6 
    you to reuse them, in which case a lot of the existing tools like DTD, schemas
    Packit Service a31ea6 
    and stylesheets may already be available. If you are looking at a
    Packit Service a31ea6 
    documentation format, DocBook should
    Packit Service a31ea6 
    handle your needs. If reuse is not possible because some semantic or use case
    Packit Service a31ea6 
    aspects are too different this will be helpful avoiding design errors like
    Packit Service a31ea6 
    targeting the vocabulary to the wrong abstraction level. In this format
    Packit Service a31ea6 
    design phase try to be synthetic and be sure to express the real content of
    Packit Service a31ea6 
    your data and use the XML structure to express the semantic and context of
    Packit Service a31ea6 
    those data.
    Packit Service a31ea6
    Packit Service a31ea6 
    DTD rules:
    Packit Service a31ea6
    Packit Service a31ea6 
    Building a DTD (Document Type Definition) or a Schema describing the
    Packit Service a31ea6 
    structure allowed by instances is the core of the design process of the
    Packit Service a31ea6 
    vocabulary. Here are a few tips:
    Packit Service a31ea6
      Packit Service a31ea6 
        
    • use significant words for the element and attributes names.
      		•
      Packit Service a31ea6 
        
    • do not use attributes for general textual content, attributes
      		•
      Packit Service a31ea6 
          will be modified by the parser before reaching the application,
      Packit Service a31ea6 
          spaces and line informations will be modified.
      Packit Service a31ea6 
        
    • use single elements for every string that might be subject to
      		•
      Packit Service a31ea6 
          localization. The canonical way to localize XML content is to use
      Packit Service a31ea6 
          siblings element carrying different xml:lang attributes like in the
      Packit Service a31ea6 
          following:
      Packit Service a31ea6 
          
      <welcome>
      Packit Service a31ea6 
        <msg xml:lang="en">hello</msg>
      Packit Service a31ea6 
        <msg xml:lang="fr">bonjour</msg>
      Packit Service a31ea6 
      </welcome>
      Packit Service a31ea6
      Packit Service a31ea6 
        
    • use attributes to refine the content of an element but avoid them for
      		•
      Packit Service a31ea6 
          more complex tasks, attribute parsing is not cheaper than an element and
      Packit Service a31ea6 
          it is far easier to make an element content more complex while attribute
      Packit Service a31ea6 
          will have to remain very simple.
      Packit Service a31ea6
      Packit Service a31ea6
      Packit Service a31ea6 
      Versioning:
      Packit Service a31ea6
      Packit Service a31ea6 
      As part of the design, make sure the structure you define will be usable
      Packit Service a31ea6 
      for future extension that you may not consider for the current version. There
      Packit Service a31ea6 
      are two parts to this:
      Packit Service a31ea6
        Packit Service a31ea6 
          
      • Make sure the instance contains a version number which will allow to
        		•
        Packit Service a31ea6 
            make backward compatibility easy. Something as simple as having a
        Packit Service a31ea6 
            version="1.0" on the root document of the instance is
        Packit Service a31ea6 
            sufficient.
        Packit Service a31ea6 
          
      • While designing the code doing the analysis of the data provided by the
        		•
        Packit Service a31ea6 
            XML parser, make sure you can work with unknown versions, generate a UI
        Packit Service a31ea6 
            warning and process only the tags recognized by your version but keep in
        Packit Service a31ea6 
            mind that you should not break on unknown elements if the version
        Packit Service a31ea6 
            attribute was not in the recognized set.
        Packit Service a31ea6
        Packit Service a31ea6
        Packit Service a31ea6 
        Other design parts:
        Packit Service a31ea6
        Packit Service a31ea6 
        While defining you vocabulary, try to think in term of other usage of your
        Packit Service a31ea6 
        data, for example how using XSLT stylesheets could be used to make an HTML
        Packit Service a31ea6 
        view of your data, or to convert it into a different format. Checking XML
        Packit Service a31ea6 
        Schemas and looking at defining an XML Schema with a more complete
        Packit Service a31ea6 
        validation and datatyping of your data structures is important, this helps
        Packit Service a31ea6 
        avoiding some mistakes in the design phase.
        Packit Service a31ea6
        Packit Service a31ea6 
        Namespace:
        Packit Service a31ea6
        Packit Service a31ea6 
        If you expect your XML vocabulary to be used or recognized outside of your
        Packit Service a31ea6 
        application (for example binding a specific processing from a graphic shell
        Packit Service a31ea6 
        like Nautilus to an instance of your data) then you should really define an
        Packit Service a31ea6 
        href="http://www.w3.org/TR/REC-xml-names/">XML namespace for your
        Packit Service a31ea6 
        vocabulary. A namespace name is an URL (absolute URI more precisely). It is
        Packit Service a31ea6 
        generally recommended to anchor it as an HTTP resource to a server associated
        Packit Service a31ea6 
        with the software project. See the next section about this. In practice this
        Packit Service a31ea6 
        will mean that XML parsers will not handle your element names as-is but as a
        Packit Service a31ea6 
        couple based on the namespace name and the element name. This allows it to
        Packit Service a31ea6 
        recognize and disambiguate processing. Unicity of the namespace name can be
        Packit Service a31ea6 
        for the most part guaranteed by the use of the DNS registry. Namespace can
        Packit Service a31ea6 
        also be used to carry versioning information like:
        Packit Service a31ea6
        Packit Service a31ea6 
        "http://www.gnome.org/project/projectname/1.0/"
        Packit Service a31ea6
        Packit Service a31ea6 
        An easy way to use them is to make them the default namespace on the
        Packit Service a31ea6 
        root element of the XML instance like:
        Packit Service a31ea6 
        <structure xmlns="http://www.gnome.org/project/projectname/1.0/">
        Packit Service a31ea6 
          <data>
        Packit Service a31ea6 
          ...
        Packit Service a31ea6 
          </data>
        Packit Service a31ea6 
        </structure>
        Packit Service a31ea6
        Packit Service a31ea6 
        In that document, structure and all descendant elements like data are in
        Packit Service a31ea6 
        the given namespace.
        Packit Service a31ea6
        Packit Service a31ea6 
        Canonical URL
        Packit Service a31ea6
        Packit Service a31ea6 
        As seen in the previous namespace section, while XML processing is not
        Packit Service a31ea6 
        tied to the Web there is a natural synergy between both. XML was designed to
        Packit Service a31ea6 
        be available on the Web, and keeping the infrastructure that way helps
        Packit Service a31ea6 
        deploying the XML resources. The core of this issue is the notion of
        Packit Service a31ea6 
        "Canonical URL" of an XML resource. The resource can be an XML document, a
        Packit Service a31ea6 
        DTD, a stylesheet, a schema, or even non-XML data associated with an XML
        Packit Service a31ea6 
        resource, the canonical URL is the URL where the "master" copy of that
        Packit Service a31ea6 
        resource is expected to be present on the Web. Usually when processing XML a
        Packit Service a31ea6 
        copy of the resource will be present on the local disk, maybe in
        Packit Service a31ea6 
        /usr/share/xml or /usr/share/sgml maybe in /opt or even on C:\projectname\
        Packit Service a31ea6 
        (horror !). The key point is that the way to name that resource should be
        Packit Service a31ea6 
        independent of the actual place where it resides on disk if it is available,
        Packit Service a31ea6 
        and the fact that the processing will still work if there is no local copy
        Packit Service a31ea6 
        (and that the machine where the processing is connected to the Internet).
        Packit Service a31ea6
        Packit Service a31ea6 
        What this really means is that one should never use the local name of a
        Packit Service a31ea6 
        resource to reference it but always use the canonical URL. For example in a
        Packit Service a31ea6 
        DocBook instance the following should not be used:
        Packit Service a31ea6 
        <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
        Packit Service a31ea6
        Packit Service a31ea6
        Packit Service a31ea6 
                                 "/usr/share/xml/docbook/4.2/docbookx.dtd">
        Packit Service a31ea6
        Packit Service a31ea6 
        But always reference the canonical URL for the DTD:
        Packit Service a31ea6 
        <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
        Packit Service a31ea6
        Packit Service a31ea6
        Packit Service a31ea6 
                                 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
        Packit Service a31ea6
        Packit Service a31ea6 
        Similarly, the document instance may reference the
        Packit Service a31ea6 
        href="http://www.w3.org/TR/xslt">XSLT stylesheets needed to process it to
        Packit Service a31ea6 
        generate HTML, and the canonical URL should be used:
        Packit Service a31ea6 
        <?xml-stylesheet
        Packit Service a31ea6 
          href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"
        Packit Service a31ea6 
          type="text/xsl"?>
        Packit Service a31ea6
        Packit Service a31ea6 
        Defining the canonical URL for the resources needed should obey a few
        Packit Service a31ea6 
        simple rules similar to those used to design namespace names:
        Packit Service a31ea6
          Packit Service a31ea6 
            
        • use a DNS name you know is associated to the project and will be
          		•
          Packit Service a31ea6 
              available on the long term
          Packit Service a31ea6 
            
        • within that server space, reserve the right to the subtree where you
          		•
          Packit Service a31ea6 
              intend to keep those data
          Packit Service a31ea6 
            
        • version the URL so that multiple concurrent versions of the resources
          		•
          Packit Service a31ea6 
              can be hosted simultaneously
          Packit Service a31ea6
          Packit Service a31ea6
          Packit Service a31ea6 
          Catalog setup
          Packit Service a31ea6
          Packit Service a31ea6 
          How catalogs work:
          Packit Service a31ea6
          Packit Service a31ea6 
          The catalogs are the technical mechanism which allow the XML processing
          Packit Service a31ea6 
          tools to use a local copy of the resources if it is available even if the
          Packit Service a31ea6 
          instance document references the canonical URL.
          Packit Service a31ea6 
          href="http://www.oasis-open.org/committees/entity/">XML Catalogs are
          Packit Service a31ea6 
          anchored in the root catalog (usually /etc/xml/catalog or
          Packit Service a31ea6 
          defined by the user). They are a tree of XML documents defining the mappings
          Packit Service a31ea6 
          between the canonical naming space and the local installed ones, this can be
          Packit Service a31ea6 
          seen as a static cache structure.
          Packit Service a31ea6
          Packit Service a31ea6 
          When the XML processor is asked to process a resource it will
          Packit Service a31ea6 
          automatically test for a locally available version in the catalog, starting
          Packit Service a31ea6 
          from the root catalog, and possibly fetching sub-catalog resources until it
          Packit Service a31ea6 
          finds that the catalog has that resource or not. If not the default
          Packit Service a31ea6 
          processing of fetching the resource from the Web is done, allowing in most
          Packit Service a31ea6 
          case to recover from a catalog miss. The key point is that the document
          Packit Service a31ea6 
          instances are totally independent of the availability of a catalog or from
          Packit Service a31ea6 
          the actual place where the local resource they reference may be installed.
          Packit Service a31ea6 
          This greatly improves the management of the documents in the long run, making
          Packit Service a31ea6 
          them independent of the platform or toolchain used to process them. The
          Packit Service a31ea6 
          figure below tries to express that  mechanism:
          Packit Service a31ea6 
          alt="Picture describing the catalog ">
          Packit Service a31ea6
          Packit Service a31ea6 
          Usual catalog setup:
          Packit Service a31ea6
          Packit Service a31ea6 
          Usually catalogs for a project are setup as a 2 level hierarchical cache,
          Packit Service a31ea6 
          the root catalog containing only "delegates" indicating a separate subcatalog
          Packit Service a31ea6 
          dedicated to the project. The goal is to keep the root catalog clean and
          Packit Service a31ea6 
          simplify the maintenance of the catalog by using separate catalogs per
          Packit Service a31ea6 
          project. For example when creating a catalog for the
          Packit Service a31ea6 
          href="http://www.w3.org/TR/xhtml1">XHTML1 DTDs, only 3 items are added to
          Packit Service a31ea6 
          the root catalog:
          Packit Service a31ea6 
            <delegatePublic publicIdStartString="-//W3C//DTD XHTML 1.0"
          Packit Service a31ea6 
                            catalog="file:///usr/share/sgml/xhtml1/xmlcatalog"/>
          Packit Service a31ea6 
            <delegateSystem systemIdStartString="http://www.w3.org/TR/xhtml1/DTD"
          Packit Service a31ea6 
                            catalog="file:///usr/share/sgml/xhtml1/xmlcatalog"/>
          Packit Service a31ea6 
            <delegateURI uriStartString="http://www.w3.org/TR/xhtml1/DTD"
          Packit Service a31ea6 
                            catalog="file:///usr/share/sgml/xhtml1/xmlcatalog"/>
          Packit Service a31ea6
          Packit Service a31ea6 
          They are all "delegates" meaning that if the catalog system is asked to
          Packit Service a31ea6 
          resolve a reference corresponding to them, it has to lookup a sub catalog.
          Packit Service a31ea6 
          Here the subcatalog was installed as
          Packit Service a31ea6 
          /usr/share/sgml/xhtml1/xmlcatalog in the local tree. That
          Packit Service a31ea6 
          decision is left to the sysadmin or the packager for that system and may
          Packit Service a31ea6 
          obey different rules, but the actual place on the filesystem (or on a
          Packit Service a31ea6 
          resource cache on the local network) will not influence the processing as
          Packit Service a31ea6 
          long as it is available. The first rule indicate that if the reference uses a
          Packit Service a31ea6 
          PUBLIC identifier beginning with the
          Packit Service a31ea6
          Packit Service a31ea6 
          "-//W3C//DTD XHTML 1.0"
          Packit Service a31ea6
          Packit Service a31ea6 
          substring, then the catalog lookup should be limited to the specific given
          Packit Service a31ea6 
          lookup catalog. Similarly the second and third entries indicate those
          Packit Service a31ea6 
          delegation rules for SYSTEM, DOCTYPE or normal URI references when the URL
          Packit Service a31ea6 
          starts with the "http://www.w3.org/TR/xhtml1/DTD" substring
          Packit Service a31ea6 
          which indicates the location on the W3C server where the XHTML1 resources are
          Packit Service a31ea6 
          stored. Those are the beginning of all Canonical URLs for XHTML1 resources.
          Packit Service a31ea6 
          Those three rules are sufficient in practice to capture all references to XHTML1
          Packit Service a31ea6 
          resources and direct the processing tools to the right subcatalog.
          Packit Service a31ea6
          Packit Service a31ea6 
          A subcatalog example:
          Packit Service a31ea6
          Packit Service a31ea6 
          Here is the complete subcatalog used for XHTML1:
          Packit Service a31ea6 
          <?xml version="1.0"?>
          Packit Service a31ea6 
          <!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
          Packit Service a31ea6 
                    "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
          Packit Service a31ea6 
          <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
          Packit Service a31ea6 
            <public publicId="-//W3C//DTD XHTML 1.0 Strict//EN"
          Packit Service a31ea6 
                    uri="xhtml1-20020801/DTD/xhtml1-strict.dtd"/>
          Packit Service a31ea6 
            <public publicId="-//W3C//DTD XHTML 1.0 Transitional//EN"
          Packit Service a31ea6 
                    uri="xhtml1-20020801/DTD/xhtml1-transitional.dtd"/>
          Packit Service a31ea6 
            <public publicId="-//W3C//DTD XHTML 1.0 Frameset//EN"
          Packit Service a31ea6 
                    uri="xhtml1-20020801/DTD/xhtml1-frameset.dtd"/>
          Packit Service a31ea6 
            <rewriteSystem systemIdStartString="http://www.w3.org/TR/xhtml1/DTD"
          Packit Service a31ea6 
                    rewritePrefix="xhtml1-20020801/DTD"/>
          Packit Service a31ea6 
            <rewriteURI uriStartString="http://www.w3.org/TR/xhtml1/DTD"
          Packit Service a31ea6 
                    rewritePrefix="xhtml1-20020801/DTD"/>
          Packit Service a31ea6 
          </catalog>
          Packit Service a31ea6
          Packit Service a31ea6 
          There are a few things to notice:
          Packit Service a31ea6
            Packit Service a31ea6 
              
          • this is an XML resource, it points to the DTD using Canonical URLs, the
            		•
            Packit Service a31ea6 
                root element defines a namespace (but based on an URN not an HTTP
            Packit Service a31ea6 
              URL).
            Packit Service a31ea6 
              
          • it contains 5 rules, the 3 first ones are direct mapping for the 3
            		•
            Packit Service a31ea6 
                PUBLIC identifiers defined by the XHTML1 specification and associating
            Packit Service a31ea6 
                them with the local resource containing the DTD, the 2 last ones are
            Packit Service a31ea6 
                rewrite rules allowing to build the local filename for any URL based on
            Packit Service a31ea6 
                "http://www.w3.org/TR/xhtml1/DTD", the local cache simplifies the rules by
            Packit Service a31ea6 
                keeping the same structure as the on-line server at the Canonical URL
            Packit Service a31ea6 
              
          • the local resources are designated using URI references (the uri or
            		•
            Packit Service a31ea6 
                rewritePrefix attributes), the base being the containing sub-catalog URL,
            Packit Service a31ea6 
                which means that in practice the copy of the XHTML1 strict DTD is stored
            Packit Service a31ea6 
                locally in
            Packit Service a31ea6 
                /usr/share/sgml/xhtml1/xmlcatalog/xhtml1-20020801/DTD/xhtml1-strict.dtd
            Packit Service a31ea6
            Packit Service a31ea6
            Packit Service a31ea6 
            Those 5 rules are sufficient to cover all references to the resources held
            Packit Service a31ea6 
            at the Canonical URL for the XHTML1 DTDs.
            Packit Service a31ea6
            Packit Service a31ea6 
            Package integration
            Packit Service a31ea6
            Packit Service a31ea6 
            Creating and removing catalogs should be handled as part of the process of
            Packit Service a31ea6 
            (un)installing the local copy of the resources. The catalog files being XML
            Packit Service a31ea6 
            resources should be processed with XML based tools to avoid problems with the
            Packit Service a31ea6 
            generated files, the xmlcatalog command coming with libxml2 allows you to create
            Packit Service a31ea6 
            catalogs, and add or remove rules at that time. Here is a complete example
            Packit Service a31ea6 
            coming from the RPM for the XHTML1 DTDs post install script. While this example
            Packit Service a31ea6 
            is platform and packaging specific, this can be useful as a an example in
            Packit Service a31ea6 
            other contexts:
            Packit Service a31ea6 
            %post
            Packit Service a31ea6 
            CATALOG=/usr/share/sgml/xhtml1/xmlcatalog
            Packit Service a31ea6 
            #
            Packit Service a31ea6 
            # Register it in the super catalog with the appropriate delegates
            Packit Service a31ea6 
            #
            Packit Service a31ea6 
            ROOTCATALOG=/etc/xml/catalog
            Packit Service a31ea6
            Packit Service a31ea6 
            if [ ! -r $ROOTCATALOG ]
            Packit Service a31ea6 
            then
            Packit Service a31ea6 
                /usr/bin/xmlcatalog --noout --create $ROOTCATALOG
            Packit Service a31ea6 
            fi
            Packit Service a31ea6
            Packit Service a31ea6 
            if [ -w $ROOTCATALOG ]
            Packit Service a31ea6 
            then
            Packit Service a31ea6 
                    /usr/bin/xmlcatalog --noout --add "delegatePublic" \
            Packit Service a31ea6 
                            "-//W3C//DTD XHTML 1.0" \
            Packit Service a31ea6 
                            "file://$CATALOG" $ROOTCATALOG
            Packit Service a31ea6 
                    /usr/bin/xmlcatalog --noout --add "delegateSystem" \
            Packit Service a31ea6 
                            "http://www.w3.org/TR/xhtml1/DTD" \
            Packit Service a31ea6 
                            "file://$CATALOG" $ROOTCATALOG
            Packit Service a31ea6 
                    /usr/bin/xmlcatalog --noout --add "delegateURI" \
            Packit Service a31ea6 
                            "http://www.w3.org/TR/xhtml1/DTD" \
            Packit Service a31ea6 
                            "file://$CATALOG" $ROOTCATALOG
            Packit Service a31ea6 
            fi
            Packit Service a31ea6
            Packit Service a31ea6 
            The XHTML1 subcatalog is not created on-the-fly in that case, it is
            Packit Service a31ea6 
            installed as part of the files of the packages. So the only work needed is to
            Packit Service a31ea6 
            make sure the root catalog exists and register the delegate rules.
            Packit Service a31ea6
            Packit Service a31ea6 
            Similarly, the script for the post-uninstall just remove the rules from the
            Packit Service a31ea6 
            catalog:
            Packit Service a31ea6 
            %postun
            Packit Service a31ea6 
            #
            Packit Service a31ea6 
            # On removal, unregister the xmlcatalog from the supercatalog
            Packit Service a31ea6 
            #
            Packit Service a31ea6 
            if [ "$1" = 0 ]; then
            Packit Service a31ea6 
                CATALOG=/usr/share/sgml/xhtml1/xmlcatalog
            Packit Service a31ea6 
                ROOTCATALOG=/etc/xml/catalog
            Packit Service a31ea6
            Packit Service a31ea6 
                if [ -w $ROOTCATALOG ]
            Packit Service a31ea6 
                then
            Packit Service a31ea6 
                        /usr/bin/xmlcatalog --noout --del \
            Packit Service a31ea6 
                                "-//W3C//DTD XHTML 1.0" $ROOTCATALOG
            Packit Service a31ea6 
                        /usr/bin/xmlcatalog --noout --del \
            Packit Service a31ea6 
                                "http://www.w3.org/TR/xhtml1/DTD" $ROOTCATALOG
            Packit Service a31ea6 
                        /usr/bin/xmlcatalog --noout --del \
            Packit Service a31ea6 
                                "http://www.w3.org/TR/xhtml1/DTD" $ROOTCATALOG
            Packit Service a31ea6 
                fi
            Packit Service a31ea6 
            fi
            Packit Service a31ea6
            Packit Service a31ea6 
            Note the test against $1, this is needed to not remove the delegate rules
            Packit Service a31ea6 
            in case of upgrade of the package.
            Packit Service a31ea6
            Packit Service a31ea6 
            Following the set of guidelines and tips provided in this document should
            Packit Service a31ea6 
            help deploy the XML resources in the GNOME framework without much pain and
            Packit Service a31ea6 
            ensure a smooth evolution of the resource and instances.
            Packit Service a31ea6
            Packit Service a31ea6 
            Daniel Veillard
            Packit Service a31ea6
            Packit Service a31ea6 
            $Id$
            Packit Service a31ea6
            Packit Service a31ea6
            Packit Service a31ea6 
            </body>
            Packit Service a31ea6 
            </html>

            Powered by Pagure 5.13.3

            SSH Hostkey/Fingerprint | Documentation