TIP #55

Dublin Core element set

• This element is a string containing the name of the distributed package. The name may consist only of alphanumeric characters, colons, dashes and underscores. This name should correspond to the name of the package defined by this distribution (that is, the code should contain package provide xyzzy where xyzzy is the value of this element.
• Care must be taken to make this name unique among the package names in the archive. To overcome this, namespace style names separated by double colons should be used.
• Examples: xyzzy, tcllib, xml::soap, cassidy::wonderful-package_2

• This element is a string containing the version of the package. It consists of 4 components separated by full stops. The components are major version, minor version, maturity and level; and are written in this order.
• The major and minor version components are integer numbers greater than or equal to zero.
• The component maturity is restricted to the values a, b. The represent the maturity states alpha, beta respectively. For a production release, this component can be omitted.
• The level component allows a more fine-grained differentiation of maturity levels. When a package has maturity production the level component is often called the patchlevel of the package. If the level component is zero, it may be ommitted.
• The period each side of the maturity component may be ommited.
• Valid version numbers can be decoded via the following regular expression:

   regexp {([0-9]+)\.([0-9]+)\.?([ab])?\.?([0-9]*)} $ver => major minor maturity level

• Examples: 8.4.0 8.4a1 2.5.b.5

• This element is a free form string containing a one sentence description of the package contained in the distribution.
• Example: Installer Tools for Tcl Packages

• This element is a string containing the name of the person, organisation or service responsible for the creation of the package optionally followed by the email address of the author in angle brackets [1]. More detail about an author can be provided in a seperate object in the description and if this is provided the email address should be used as the value of the Name field in that object.
• If there is more than one author this field may appear multiple times.
• Email addresses may be obfuscated to avoid spam harvesters.
• Example: Steve Cassidy <Steve.Cassidy at mq dot edu dot au>

• This element is a string analogous to the Creator element which contains the name of the current maintainer of the package.

• This element is a string analogous to the Creator element which contains the name of a contributor to the package.

• Typically, a Rights element will contain a rights management statement for the resource, or reference a service providing such information. This will usually be a reference to the license under which the package is distributed. This can be a free form string naming the license or a URL refering to a document containing the text of the license.
• If the Rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource. * Examples: BSD, Artistic license

• This element is a string containing an url refering to a document or site at which the information about the package can be found. This url is not the location of the distribution, as this might be part of a larger repository separate from the package site.
• Example: http://www.ics.mq.edu.au/~cassidy/tcl/

• This element is the release data of the package in the form YYYY-MM-DD.
• YYYY is a four-digit integer number greater than zero denoting the year the distribution was released.
• MM is a two-digit integer number greater than zero and less than 13. It is padded with zero at the front if it less than 10. It denotes the month the distribution was released. The number 1 represents January, 2 represents February; and 12 represents December.
• DD is a two-digit integer number greater than zero and less than 32. It is and padded with zero at the front if less than 10. It denotes the day in the month the distribution was released.
• A valid data string can be obtained with the tcl command

 [clock format [clock seconds] -format "%Y-%m-%d"]

• Example: 2002-01-23
• (The DC element is Date but it can be refined to Created, Available, Applies)

• This element is a free form string briefly describing the package.

• This element is a string describing one of the architectures included in the distribution. As a distribution is allowed to contain the files for several architectures, this element may appear multiple times and should correspond to a directory in the distribution.

• Names a package that must be installed for this package to operate properly. This should have the same format as the package require command, eg. ?-exact? package ?version?.
• Example: http 2.0

• Declares a strong, but not absolute dependancy on another package. In most cases this package should be installed unless the user has specific reasons not to install them.

• Declares a package which would enhance the functionality of this package but which is not a requirement for the basic functionality of the package.

• Names a package with which can't be installed alongside this package. The syntax is the same as for Require. If a conflicting package is present on the system, an installer might offer an option of removing it or not installing this package.

• The topic or content of the package expressed as a set of Keywords. At some future time, a set of canonical keywords may be established by a repository manager.

• This element is a string containing the name of the person, organisation or service responsible for the packaging of the software optionally followed by an email address in angle brackets [2].
• If there is more than one author this field may appear multiple times.
• Email addresses may be obfuscated to avoid spam harvesters.
• Example: Steve Cassidy <Steve.Cassidy at mq dot edu dot au>

• This element is a string describing the type of resource
• The value is limited to the set source, installable, documentation
• source is the source of an application or package
• installable is a package bundled in such a way that it can be installed automatically. The recommended format is that described in TIP55 but a more operational definition might be developed.
• documentation is a documentation file or bundle of these.
• Additional types may be added in future as the need arises

NICS

See also edit

• CANTCL

• Home
• Recent changes
• Help
• WhoAmI/Logout
• Create new page
• Random page
• Previous page
• Next page
• 
  
• Add comments
• Edit
• History
• Edit summary
• References