MetaLex

Guidelines

This document lists design goals, technologies, encoding guidelines, standards for interpretation of metadata elements, and a standardized terminology for talking about legal documents. The MetaLex standard intends to provide a generic and easily extensible framework for the XML encoding of the structure and contents of written public decisions, or public legal documents of a general and regulatory nature. The standard makes only minimal requirements on the structure of documents. The standard tries to adopt, as far as is practicable, relevant guidelines and standards of the World Wide Web Consortium (W3C).

The MetaLex research project was carried out in the context of the ePOWER project (IST Project 2000-28125; This project included the DTCA (Belastingdienst) in the Netherlands and the Leibniz Center for Law of the University of Amsterdam) and the LeXML initiative for XML standards for the various European jurisdictions.

This document represents a compromise that leaves certain design questions open. As the work continues, new requirements will be documented. This document is a living document, and may be revised to reflect changes in the MetaLex Working Group’s understanding. The Working Group does not anticipate substantial changes, but may decide to refine existing requirements or add new ones. The Working Group aims to facilitate and encourage adoption of this standard in the Netherlands and Europe, while at the same time keeping requirements sufficiently general for application of the XML encoding to legal documents from private organizations and other jurisdictions. This means that the standard does not try to encode the formal phrases and formulas used to position a regulation in the jurisdiction of the Netherlands or any subsumed or subsuming jurisdictions (the European Union, for instance). The standard is also language-independent, supporting multiple language versions of a legal document, and even localization of XML element names.

This document describes the MetaLex 1.3 schema. Most of this document also applies to the previous versions.

General comments about the MetaLex schema should be addressed to metalex@leibnzcenter.org. Technical comments and questions about the MetaLex schema and this document can be sent to the same address.

Design goals

This proposal aims to standardize legal documents for a number of purposes:

• Filtering on Structure Each meaningful element of the text up to a full sentence can be separately selected or changed by software through an XML API. Each element of the text is marked with an identifier that is unique in the document.
• Presentation An element is easy to transform to human-readable text with a familiar layout by application of an XSL transformation. An XSL sheet for translation to XHTML is included that preserves the identifiers of the elements so that each element has a valid URL by which it can be referenced. References to other documents are embedded as hyperlinks.
• Document Management The XML document is classified in such a way that it is possible to determine how it relates to the legal documents to which it is linked, and whether it is valid relative to those other documents.
• Knowledge Representation Because each element has an identifier, it is possible to make external statements in RDF refer to the right part of the document. RDF is syntactically sufficient to represent description logics (in OWL, the Web Ontology Language), UML, or search indices. The standard thus allows use of existing UML and OWL editors for legal knowledge representation.
• Search RDF can be used to encode inverted file indices, association rules and, if time permits, self organizing maps to search for document elements using a concept index.
• Code Generation UML or OWL descriptions can be used (with external software) to generate code in for instance Java and C++.
• Rule generation UML or OWL descriptions can be used (with external software) to generate rules for JESS and Aion DS to build decision support systems.
• Classification and Verification OWL descriptions can be translated (with external software) to DIG XML description logic to use existing description classification services and satisfiability checks.
  These services can be embedded in decision support systems.

Metalex XML is more complicated than most comparable standards. The reason is that it is motivated not just by concerns for ’smart’ search, but also with document management and maintenance of existing and future decision support software used by public authorities like the fiscal applications developed by the POWER group in the Netherlands and applications developed by the academic community. See our publications for more information on the use of MetaLex XML for content management systems and expert systems.

Overview

The MetaLex schema maps are distributed as a zip file on this website. The MetaLex schema/ map contains a number of different versions of the MetaLex schema: the Metalex monolothic schema (metalex.xsd), the MetaLex modular schema, and the MetaLex language specific schemas (suffixed with an ISO 639 two letter language code, for instance _nl for Dutch). The version found at the namespace URI (http://www.metalex.nl/latest) is the monolithic one. The modular version is particularly useful if you only use the MetaLex reference vocabulary (in MetalexRef.xsd) to refer to MetaLex objects from another XML document. The language specific schemas allow you to validate MetaLex XML documents using a localized vocabulary, but if you want to use other MetaLex functionality (like translation to RDF/OWL) you have to translate the language-specific document to generic MetaLex first using a stylesheet in a map named after the ISO 639 two letter language code (for instance transform/nl/) inside the transform/ map.

The table below lists the main elements of the metalex.xsd module and explains their use:

Metalex elements can be grouped in several types:

1. container: this type of element contains other container elements, or block elements in a defined sequence. Regulation, Part, Article, Sentence, etc.
2. block: the block element occurs in a container and contains mixed text and (inline) XML elements. The block element also accepts XML elements from other namespace. TextVersion, Annotation, etc.
3. inline: occurs inside mixed text in block elements. CiteGroup, CitationTitle, Reference, etc.

Technology

MetaLex is based on a number of standards of the World Wide web Consortium: XML, RDF, OWL, XLink, XHTML, Web naming and addressing, XSL, and XML Base.

A limitation of basic XML is the lack of a standard context-independent method for determining object identity of elements and referring to elements. The recent XLinking specifications released by the W3 Consortium create a generic facility for referring unambiguously to parts of XML documents, but is not yet supported by most tools. In addition to that there are a number of competing methods for naming objects.

The problem is that there is significant difference between the object identity of provisions in legislation, and the object identity of resources on the Internet: if legislation is an important resource there will be many copies of it going around, produced by different publishers. This makes it hard to manage content about legislation. MetaLex tries to standardize exchange of fragments of regulatory texts, and the way information about regulatory text refers to the provisions it is about.

There is an XML standard for making statements about documents in a transparent way: the Resource Description Framework (RDF). RDF, RDF Schema, and (X)HTML share support for a widely accepted standard for reference anchors embedded in XML: the Uniform Resource Identifier (URI). For optimal support by existing tools the standard consists of two schemas that are equivalent in meaning: A RDF Schema and an XML Schema. A translator between the MetaLex XML standard and the more flexible MetaLex RDF encoding for software engineers is part of the MetaLex distribution. It is also possible to translate the XML encoding to HTML.

In HTML (and optionally in RDF) the XML ID identity attribute of a document element is used to construct URI references from other documents. If a document element has no URI, then it is not possible to refer to it using HTML and RDF. It is therefore recommended to assign a URI to important MetaLex XML document elements.

There are three attributes to tell MetaLex-aware software about the URI of an element: metalex:uri, metalex:id, and xml:id. The attributes metalex:id and xml:id can only be used if it is possible to determine the XML base of the containing document. The preferred method for communication of the XML base is the xml:base attribute. MetaLex uses the following method (expressed in XSLT) to determine the URI:




#

RDF and the Semantic Web

The Resource Description Framework (RDF) is, like XML, an open standard from the World Wide Web Consortium (W3C) that is well-supported with free software. In RDF, statements are encoded as as (subject, predicate, object) triples. By describing legal concepts in different jurisdictions in an RDF dictionary (see for instance http://rdf.lexml.de) as conceptual prototypes, it is possible to identify and describe similarities and differences between legal concepts in different languages. Existing MetaData schemes for legal purposes (like JSMS and LAMS) rely on compatibility with HTML’s META tag for RDF-like statements about documents; In RDF terms that means that the subject of a statement is always the HTML document and the META tag can only be used to make statements about a document inside the document itself.

The RDF data model is based on the concept of a statement and the concept of quotation (or reification) of statements. Quotation is used to make statements about (reified) statements — the statement is treated as the subject or object of another statement. In addition to this data model additional RDF schema statements can be defined, whose meaningfulness depends on the extent to which they can be transformed to other schemas and whether there exist any applications that can validate statements against that schema with query or inference languages. Since RDF is serialized in XML documents, it is important to realize that the validity of an RDF statement is relative to an unspecified set of other statements in the memory of the validating application. There is no central authority guarding universal consistency or coherence of the semantic web and anyone can publish any truth, falsehood, opinion, or judgment.

Quotation allows one to create trust, because it allows one to express where something was stated, who stated it, who modeled a statement made by someone, and what level of guarantee they dare to associate with it. Syndication of information is based on this notion of trust. You may be willing to pay for advice, for instance, if you trust the party that gives it even if advice on the same subject is also available for free from other parties. The quotation mechanism in RDF allows others to make qualifications about statements, solving another limitation of META tags.

The figure above shows the relationship we propose between the XML encoding of a document and the RDF encoding of the same document. If a document element is encoded as a set of RDF statements, any element of it can be subject, predicate, or object of statements about the document. The RDF version of a MetaLex document as produced by XSL stylesheet metalex2owl preserves the structure of the original MetaLex XML file.

In many MetaLex RDF files not all elements have an URI (in the attribute in RDF). The other elements are written inline as so-called blank or anonymous nodes. Since RDF is not order-dependent and statements do not have to be written in the same order in which they were read, RDF tools may completely re-order the XML tree. RDF encoding therefore requires explicit sequences.

Sequences are used to represent sequences of articles, parts, sentences etc. All MetaLex classes that contain sequenced information subclass AStructuredSource, and the sequenced information subclasses APartialSource. The container membership property structuralMember and the sequence property structuralSuccessor are used to represent the sequence. This method of describing sequences also allows the representation of a hole in our knowledge about a document. Once a document contains a hole, it cannot be written in MetaLex XML anymore, because that standard cannot represent holes in the document. This notion of a hole in the document is not the same as the possible existence of holes in an index used for designation (see metalex:Index)! Article 1 may be followed by article 3 in a specific electronic document, but that doesn’t tell us whether article 2 doesn’t exist or whether the editor of the electronic document failed to insert it for some reason.

OWL is an RDF Schema that provides a number of standard logical constructs for RDF descriptions. XML schema validity constraints on documents can be partially expressed using the OWL vocabulary, and this vocabulary can be transformed to XML formats for description logic validators (Pellet, FaCT++ and Racer) and expert system rule engines (like JESS). OWL can also be used to encode complex metadata about the document. The MetaLex RDF encoding is defined in an OWL schema.

Reference Implementations

The choice for technologies is motivated to some extent by the desire to produce a standard that can be translated to as many other standard markup languages as possible. To facilitate adoption we prefer open standards for which free (or free for non-profit purpose) and open source reference implementations exist. We test compatibility with a standard set of tools. The standard parser for XML schema is Xerces (from the Apache consortium; http://www.apache.org), the standard transformer for XSL is Xalan (from the Apache consortium). The standard graph validator for RDF is based on Xerces and the Stanford API (from the University of Stanford). The standard semantic validators for RDF Schema and OWL are FaCT (at the University of Manchester), Racer (by Racer Systems GmbH), and Pellet (by MindSwap). Protege (by Stanford) is the most used editor for OWL. A good, free editor and client for FaCT is OilEd (by the University of Manchester, the Free University of Amsterdam and Interprice GmbH). SWOOP is another editor, to be used in conjunction with Pellet.

Extensibility

Embedding XML in metalex:TextType

XML tags from other namespaces can be embedded in text nodes. These nodes are of XML schema type metalex:TextType. The metalex:Introduction element, for instance, is of type metalex:TextType and allows any mixture of text and XML.

XML markup from external namespaces is copied through directly into the HTML document by the metalex2html.xsl stylesheet. One of the limitations of the standard translation of the lexnl metalex.xsd module into HTML, is that it does not specify the layout of the contents of the introduction and formats the introduction as one continuous paragraph. The

element of XHTML namespace http://www.w3.org/1999/xhtml can be directly embedded in the introduction provided that the namespace is declared. To validate the document, the location of a schema that defines the elements in the namespace must also be known. If file xhtml-framework-1.xsd contains the definition of the

paragraph element (which is in the XHTML Block Structural Module), then it can be declared as:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/1999/xhtml xhtml-framework-1.xsd">

Note that since XML markup from external namespaces (if allowed) is copied through directly by the stylesheets into target documents, it is important to check the consequences for those target documents. It may be necessary create a new stylesheet to handle translation of the embedded elements. For instance a metalex:Introduction element may contain an element of type dc:Description (dc being the Dublin Core element set from namespace http://purl.org/dc/elements/1.1/, a URL that incidentally redirects us to the RDF schema for Dublin Core) that should be displayed as a separate paragraph. An appropriate stylesheet declares:

< ?xml version="1.0"?>
xmlns:dc="http://purl.org/dc/elements/1.1/">


The line copies the XML subtrees and attributes contained in the dc:Description verbatim. This line can be replaced with if the stylesheet contains other templates that apply to XML markup that occurs in the dc:Description. Note however that Dublin Core statements are encoded in HTML documents as:

CONTENT="A textual description of the content of the resource, including abstracts in the case of document-like objects or content descriptions in the case of visual resources.">


In attribute values XML markup is not allowed, so use of XML tags in the description is bad practice in this case. It is also possible to override the imported template for metalex:Introduction completely, for instance to write the dc:Description as a META tag at the top of the HTML page.

Embedding in Other XML Namespaces

A document marked up with the MetaLex element set can be embedded as a XML subtree in other XML namespaces subject to the restrictions of the XML schema or DTD of that namespace. Note that if you filter subtrees from a MetaLex document you may have to add or remove attribute values from nodes to meet the validity restrictions outlined in section 6. Because MetaLex elements are all declared global, any XML subtree of a MetaLex document can be used to extend any other XML schema or dtd.

Language

The MetaLex XML schemas support localization of both content and XML tag names. All elements that can contain text (block elements of type metalex:TextType, metalex:MixedType and inline elements) can be marked up with a xml:lang attribute. Alternatively, it is possible to embed multiple metalex:TextVersion elements in a metalex:TextType element, each marked up with a xml:lang attribute. The xml:lang attribute is inherited by all contained elements that do not have an explicit xml:lang attribute. To localize tag names the MetaLex XML schema must be extended.

Localization of XML element names

The figure below shows the relation between the various XML schema files that are part of the standard. An XML document on the bottom leftside that adheres to schema metalexStd_nl.xsd uses the Dutch (Nederlands) XML element vocabulary for document structure and indirectly imports vocabulary metalexRef_nl.xsd and the structural requirements of metalexStd.xsd and metalexRef.xsd - the language-independent core vocabulary (in simple English). The language-specific schemas contain direct word-for-word translations (with the XML schema substitutionGroup element) to the standard vocabulary. An XML document is first transformed with an XSL transformation sheet to standard vocabulary, and the standard vocabulary can be transformed to HTML or RDF. RDF is used for further description of role and content.

Extensions built on top of the standard consist of relevant language-dependent vocabulary schemas, a standard schema that defines formal requirements, a simple XSL template that translates language-dependent schemas to standard vocabulary, an XSL template that translates the standard schema to standard-document, and optionally XSL templates for specialized presentations in HTML. The Dutch localization of element names in metalexStd_nl.xsd and metalexRef_nl.xsd and the stylesheet metalex_nl2metalex.xsl can be used as a starting point for a localization.

Validity of Attribute Values

For all attributes, except the identity attributes, it is a rule that the attribute value applies to the element to which it is attached and to all its subelements to which the same attribute can be attached, unless these carry the same attribute with another attribute value.

Strict application of the Metalex standard requires a (inferred) setting for the attributes in the temporalAttrs attribute group on each text element. Because the rules for determining the applicable values are complex, they cannot be checked with XML schema.

Determing Identity

The Metalex standard includes two attributes for determing the identity of a document element: metalex:id and metalex:uri. Only one of these is present, and its value is used to determine the URI of the legal source represented by the XML element. Note that the URI refers to the identity of the legal source. If there are multiple XML copies of the same legal source, the URI refers to all of them.

If the id attribute is used on an element, then it must be possible to establish the xml base of the XML element for RDF and XML Linking support to work. Note that XML documents on the World Wide Web do have a base() that can generally be automatically established, but this base() is lost if the document is downloaded and saved to a local disk. It is good practice to set the the xml:base attribute of the Regulation element in a Metalex XML document on the World Wide Web, so that the context is not lost if the document is saved in a local file. Note that it is possible to set the xml:base in multiple places, for instance because the XML file contains legislation taken from multiple locations on the World Wide Web. See the XML Base and XML Linking specifications on http://www.w3.org for more information on the semantics of xml:base.

Instead of the metalex:id attribute, the xml:id attribute may be used. Never specify both a metalex:id and xml:id attribute on a single element. It is an XML requirement that only one id attribute be specified on a single element: an application allowing two id attributes on an element is not XML conformant.

Instead of base() + '#' + id() the URI can also be specified directly with metalex:uri. The URI of the element identifies the legal source identified by the element. Note that it may be a URN (universal resource name).

If the name cannot be resolved through generic HTTP, then it is possible to set the metalex:resolver (on the referring element) or editor-resolver attributes. Metalex does not prescribe the operational semantics of these attributes.

Descriptive attributes

The descriptorAttrs attributes apply to all kinds of regulatory texts, and to most elements of regulatory text up to the sentence level, or even lower. Usually they are only attached to the Regulation element. All attributes take a URI value that refers to an entity that can be described in a metadata standard like RDF, Topic Maps, or GML (Geography Markup Language). These attributes interface between the legal source itself and RDF metadata about the source.

The metalex:author is the legislator or decision maker that is responsible for creating the legal source, for instance ‘the government’, ‘government and parliament’, ‘the Crown’, ‘the Minister of X’, etc. This body or person is usually created by law, so there are usually references from (constitutional) law to this entity that describes the extent of its legislative competence.

The legislator may be able to use different forms of legislative metalex:authority or legislative competence created and delegated by law. In some jurisdictions legislative competence is called legislative power. Formal law may for instance state that a Minister is able to make certain changes in formal law for specific purposes, where otherwise the Minister would not have this competence. In addition to the competence of drafting ministerial regulations the minister has a restricted competence to directly amend formal law for some specific purpose. A competence is usually created by other law, and there are textual references in that law to the competence. The competence is identified by a URI, and this URI functions as identifier for a description in RDF. A decision maker uses an authority or power created by law to make adiministrative decisions.

The attribute metalex:procedure identifies the type of procedure that resulted in the legislation. In some cases the formal legislator can produce different types of legislation depending on the type of procedure followed (for instance decrees vs. formal legislation). This may have consequences for determining Lex Superior relations between collections of legal sources.

The metalex:editor is responsible for creating and managing the MetaLex encoding of the legal source. The editor is identified by a URI, and this URI functions as identifier for a description in RDF. The identifying URI of an element identifies the element, but it is not a requirement that the URI can be resolved through generic HTTP. If it cannot be resolved through HTTP, then it is an option to set the metalex:editor-resolver attribute if a URI resolution service exists. The URI value of the resolver attribute + the identifying URI value should result in a URI that can resolved. Since URI can be assigned to legislation by editors of MetaLex data, URI resolvers for MetaLex elements should be logically linked to the editor.

The metalex:region is the spatial entity in which the rules in the regulation can be applied. It can be used in combination with RDF and GML to describe spatial extent of the regulation’s applicability. In GML and similar geospatial standards a URI is used to refer to coordinates in a coordinate reference system (CRS). The attribute metalex:region-resolver identifies a resolver for a CRS coordinate URI used in the metalex:region attribute.

The MetaLex standard does not prescribe how resolver services for URI work, or how requests to the resolver should be made. The value of the resolver attributes only take a URI identifying a resolver.

Time and Change

The Metalex standard includes two attribute groups for temporal (time-related) information about legal source: temporalAttrs and extTemporalAttrs. The attributes in temporalAttrs are sufficient for determining the temporal validity of a document element.

The attributes in extTemporalAttrs are strictly optional. They are not needed for version management. They have been added to present a coherent theory on phenomena like retroactive application, delayed application etc.

Temporal validity of a document is an issue if the document is organic in the sense that it is common practice to change the text or meaning through the publication of other documents. If this is not the case, it is usually sufficient to set the date-publication attribute.

One of the more laborious processes in legal publishing is determining what the law actually is at some date. Changes in laws are announced in separate documents and publishers must keep track of all documents from certain publication channels to be able to reconstruct what the form of an organic law is at some time point. Similarly, if you find a written decision on your doormat its validity status changes when a new written decision retracting it follows two days later. To keep track of versions the standard provides a number of attributes; The metalex:date-publication of an element is the time the element is officially published. This may be a time in the future. It is applicable to any METALex element in a document. “Publication” may mean different things in different cases. It may refer to publication in an officially sanctioned publication channel (in the Netherlands for instance Stcrt., Stb., Trb., PbEG etc. for laws and treaties) or to the date of the action by which a public decision was announced to those concerned by it. If it is not set, it is assumed to be in the distant future (an unspecified date after the last known date).

The metalex:date-enacted, the time the content becomes applicable in decisionmaking, is always later than or the same as date-publication, but before metalex:date-repealed, the time the content becomes inapplicable in decisionmaking. Between date-enacted and date-repealed the element is active, and outside this interval it is inactive. An element that is active may create some legally qualified entity (a concept, norm, power etc.) for that period. Elements that do not have an explicit date-publication, date-enacted, or date-repealed attribute inherit the value of the first ancestor in the XML parse tree that does have the attribute. If date-publication and date-enacted are not both set with different values, then the value of both attributes is equal if one of both values is available. If date-enacted and date-publication are not set, and date-repealed is set, then date-enacted is assumed to be the distant past (an unspecified date before the earliest known date). If date-repealed is not set, and date-enacted or date-publication are set, date-repealed is assumed to be the distant future. If the date in the date-publication attribute of an ancestor in the XML parse tree is after the value of the same attribute in the current element, then the value of the current element is invalid. Validity time intervals are listed in the table below:

Versioning

The metalex:date-version attribute represents the date the correctness of the content and other dates of the METALex element was last verified. This is important to determine whether the element represents a future modification to the regulation at the time of serialization. If it is, it may not be the text that eventually became active at that future date. An element is considered verified for a certain date if it is certain that the content of the element and the dates set in its attributes and attributes of child elements (inasfar as date attributes are set) are a correct representation at that date for the regulation or decision encoded. In case of an organic law, for instance, this means that to produce a versioned document one must keep track of changes and retractions of articles and parts of articles of that law in the interval from the last version that was verified to the date that is to be assigned to the new version.

These attributes are all optional and are not set unless it is certain that the value is correct. Dates that are set thus represent a degree of trust that the document is an accurate representation of reality at the metalex:date-version that the editor that created the document wishes to convey to the user. It is also obvious that the document looses its value as a normative reference as time progresses and the time-interval between date-version and today increases.

The importance of keeping track of the relations between the various documented decisions published by public bodies is made clear by considering the requirements for verification of the date-version of a collection of documents. In a fast moving domain of law like the tax domain it is quite a job to keep track of these changes. If a MetaLex element in a newly published document refers to another MetaLex element, it is important to verify whether the text in the element repeals or enacts the other element, but such a classification cannot be taken for granted). A MetaLex element may also refer to another MetaLex element to invoke its `power’. This is the case if the official author of the document obtains the power to take the decision(s) communicated in the document from a specific assignment by law, a delegation decision, or a mandate decision. Note that in such cases the element, or an ancestor element, usually becomes inactive if the element from which the power is obtained becomes inactive.

The MetaLex standard does not try to adhere to any specific model for updating documented decisions, while it does aim to choose representational primitives that adequately capture legally relevant acts on the document collection.

To automatically validate a document or to filter it while preserving these attribute values in XSL if possible, it is necessary to be able to compare dates. The XSL Standard Library at SourceForge includes some templates for rewriting dates. XSL processors are however notably inefficient for this type of operations. The METALex website (http://www.metalex.nl) includes a stylesheet for comparing and verifying date attributes.

Retroactive application et cetera

The attributes in extTemporalAttrs have been added to present a coherent theory on phenomena like retroactive application, delayed application etc. These temporal attributes are based on a theory that a provision in a regulatory text can be read as a kind of time-indexed production rule:

RULE(t1,t2): IF CONDITIONS(t3,t4) THEN EFFECTS(t5,t6).

Between date enactment t1 and date-repeal t2 the rule is active, and therefore can be applied. The events to which is it applied must have happened between metalex:date-start-efficacy t3 and metalex:date-end-efficacy t4, the time interval in which the rule is capable of producing an effect. The effect itself exists somewhere in the time interval between metalex:date-start-effect t5 and metalex:date-end-effect t6. The duration attributes represent a time interval between two date attributes and should be consistent with the values of the related date attributes.

These attributes do not apply to the time interval in which the legal source itself is part of the legal corpus, but to the time interval of efficacy in which the events to which the legal source is applied happened, and the time interval in which the legal source can produce a legal effect (in other words: the time interval in which the judge, or a civil servant for instance, can take binding legal decisions based on the legal source).

Note that retroactive applicability does not usually refer to the possibility of making decisions using a regulation that does not exist yet, but instead to the possibility of applying the regulation to events that happened before the enactment of the regulatory text.
If multiple interpretations are possible, or if the length of the time interval depends on the exact case, choose the largest time interval possible.

The metalex:date-start-efficacy attribute can for instance be set to specify that a new provision is applied to cases pending at the time of the regulation’s enactment. If a regulation sets an effective date before the date of publication and enactment, this effective date refers to the date at which certain acts have occurred. It is not intended to mean that a court can apply the regulation before it is published or enacted. It is common in the legal profession to consider retroactive application as enactment before publication, but for the purposes of this schema this view is not really defendable. The dates set on text elements in MetaLex are primarily intended for versioning and verification of the integrity of hyperlinks. The relation between the time interval set in a text element and the time point at which some relevant event happened, or time interval in which some state of affairs pertains, is of secondary importance.

We do realize that to the user of a search engine retroactive and delayed application are very important, but we do not allow interpretations of enactment and repeal that result in enactment before publication, or the active co-existence of different versions of the same legal source at the same time depending on the case at hand. Because these phenomena are common, and the omission of a clear statement on the distinction between different contexts of use leads to abuse of date attributes for purposes for which they were not intended, we added these attributes.

These attributes are based on a simple theory predicting that the use of three time intervals (activity, efficacy, and effectiveness) will generally speaking be enough to cover the needs of most users. These attributes do not, however, solve all problems with the interpretation of whether the legal source applies to some event in the outside world. There is for instance an important difference between events that happen instantaneously (a traffic violation) and enduring states (a life insurance policy). Complicated temporal conditions on provisions simply cannot be captured in XML attributes.