Date: 09/18/05 09:03:53
Subject:
![]()
![]()
Each meta element
specifies a property/value pair. ... For
speakers of US English --> <meta property="keywords"
xml:lang="en-us">vacation, Greece, ...
www.w3.org/TR/2005/WD-xhtml2-20050527/mod-meta.html
- 30k -
Cached -
Similar pages |
22. XHTML
Metainformation Module
This section is normative.
The Metainformation Module defines elements that allow the
definition of relationships. These may relate to:
- the document itself,
- items external to the document, or
- other items of metadata within the document.
Note that this module is dependent upon the
Metainformation Attributes module. The attributes defined
therein are available on the elements defined in this module, and
their semantics are the essential part of how these elements behave.
Elements and attributes in this module are:
| Elements |
Attributes |
Content Model |
| link |
Common |
( link | meta )* |
| meta |
Common |
( PCDATA |
Text )* |
Implementation:
RELAX NG
Attributes
- The
Common collection
- A collection of other attribute collections, including:
Bi-directional,
Core,
Edit,
Embedding,
Events,
Forms,
Hypertext,
I18N,
Map, and
Metainformation.
This element defines a link.
Link conveys relationship information that may be rendered by
user agents in a variety of ways (e.g., a tool-bar with a drop-down
menu of links). User agents should enable
activation of links and the retrieval of link targets. Since
link elements may have no content, information from the
rel and
title attributes should be used when labelling links.
This example illustrates how several
link definitions may appear in the
head section of a document. The current document is
"Chapter2.html". The
rel attribute specifies the relationship of the linked
document with the current document. The values "Index", "Next",
and "Prev" are explained in the section on the attribute
rel.
<head>
<title>Chapter 2</title>
<link rel="index" href="../index.html"/>
<link rel="next" href="Chapter3.html"/>
<link rel="prev" href="Chapter1.html"/>
</head>
22.1.1. Forward
and reverse links
While the
rel attribute specifies a relationship from this
document to another resource, the
rev attribute specifies the reverse relationship.
Consider two documents A and B.
Document A: <link href="docB" rel="index"/>
Has exactly the same meaning as:
Document B: <link href="docA" rev="index"/>
namely that document B is the index for document A.
Both the
rel and
rev attributes may be specified simultaneously.
22.1.2. Links
and search engines
Authors may use the
link element to provide a variety of information to search
engines, including:
- Links to alternate versions of a document, written in
another human language.
- Links to alternate versions of a document, designed for
different media, for instance a version especially suited for
printing.
- Links to the starting page of a collection of documents.
The examples below illustrate how language information, media
types, and link types may be combined to improve document handling
by search engines.
The following example shows how to use the
hreflang attribute to indicate to a search engine where to
find other language versions of a document. Note that for the
sake of the example the
xml:lang attribute has been used to indicate that the value
of the
title attribute for the
link element designating the French manual is in French.
<html ... xml:lang="en">
<head>
<title>The manual in English</title>
<link title="The manual in Dutch"
rel="alternate"
hreflang="nl"
href="http://example.com/manual/dutch.html"/>
<link title="La documentation en Français"
rel="alternate"
hreflang="fr" xml:lang="fr"
href="http://example.com/manual/french.html"/>
</head>
In the following example, we tell search engines where to find
the printed version of a manual.
<head>
<title>Reference manual</title>
<link media="print"
title="The manual in PostScript"
hreftype="application/postscript"
rel="alternate"
href="http://example.com/manual/postscript.ps"/>
</head>
In the following example, we tell search engines where to find
the front page of a collection of documents.
<head>
<title>Reference manual -- Chapter 5</title>
<link rel="start" title="The first chapter of the manual"
hreftype="application/xhtml+xml"
href="http://example.com/manual/start.html"/>
</head>
Attributes
- The
Common collection
- A collection of other attribute collections, including:
Bi-directional,
Core,
Edit,
Embedding,
Events,
Forms,
Hypertext,
I18N,
Map, and
Metainformation.
The
meta element can be used to identify properties of a document
(e.g., author, expiration date, a list of key words, etc.) and
assign values to those properties. This specification defines a
small normative set of properties, but users may extend this set as
described for the
property attribute.
Each
meta element specifies a property/value pair. The
property attribute identifies the property and the content of
the element or the value of the
content attribute specifies the property's value.
For example, the following declaration sets a value for the
Author property:
Example
<meta property="dc:creator">Steven Pemberton</meta>
Note. The
meta element is a generic mechanism for specifying metadata.
However, some XHTML elements and attributes already handle
certain pieces of metadata and may be used by authors instead of
meta to specify those pieces: the
title element, the
address element, the
edit and related attributes, the
title attribute, and the
cite attribute.
Note. When a property specified by a
meta element takes a value that is a
URI, some authors
prefer to specify the
metadata via the
link element. Thus, the following metadata declaration:
Example
<meta property="dc:identifier">
http://www.rfc-editor.org/rfc/rfc3236.txt
</meta>
might also be written:
Example
<link rel="dc:identifier"
href="http://www.rfc-editor.org/rfc/rfc3236.txt" />
22.2.1. meta
and search engines
A common use for
meta is to specify keywords that a
search engine may use
to improve the quality of search results. When several
meta elements provide language-dependent information about a
document, search engines may filter on the
xml:lang attribute to display search results using the language
preferences of the user. For example,
Example
<!-- For speakers of US English -->
<meta property="keywords"
xml:lang="en-us">vacation, Greece, sunshine</meta>
<!-- For speakers of British English -->
<meta property="keywords"
xml:lang="en">holiday, Greece, sunshine</meta>
<!-- For speakers of French -->
<meta property="keywords"
xml:lang="fr">vacances, Grčce, soleil</meta>
The effectiveness of search engines can also be increased by
using the
link element to specify links to translations of the document in
other languages, links to versions of the document in other media
(e.g., PDF), and, when the document is part of a collection, links
to an appropriate starting point for browsing the collection.
22.3. Literals and
Resources
There are two types of properties that some item can have. The
first is a simple string value, which is useful for specifying
properties such as dates, names, numbers and so on:
Example
this document was written on "March 21st, 2004"
This is not so useful though when trying to uniquely identify
items that could occur in other places. Take the example of the
document's author being "Mark Birbeck":
Example
this document was written by "Mark Birbeck"
Since there are other people called Mark Birbeck, then we won't
know which of them wrote what. We get round this problem by allowing
the value referred to, to be a URI. For example:
Example
this document was written by
<http://example.com/people/MarkBirbeck/654>
We distinguish these two types of properties by calling the first
a 'string literal' and the second a 'resource'.
NOTE: Of course there is nothing to stop two people from using
this URI to identify two completely different people. But in general
URIs are accepted as a convenient way to identify a specific item.
22.4. Document
Properties
The simplest piece of metadata is a string literal attached to
the containing document. This can be specified using
meta. For example:
Example
<head>
<meta property="dc:creator">Mark Birbeck</meta>
<meta property="dc:created" content="2004-03-20" />
</head>
which states that:
Example
this document has an 'author' property of "Mark Birbeck";
this document has a 'created' property of "2004-03-20".
It is also possible to include mark-up in the string. This will
always be part of the string's value - in other words, no matter
what the mark-up is, it will never be processed as if it were
anything other than the value of the property:
Example
<head>
<meta property="dc:creator" content="Albert Einstein" />
<meta property="dc:title">E = mc<sup>2</sup>: The Most Urgent Problem
of Our Time</meta>
</head>
states that:
Example
this document has an 'author' property of "Albert Einstein";
this document has a 'title' property of
"E = mc<sup>2</sup>: The Most Urgent Problem of Our Time".
However, just because the mark-up is not processed as mark-up
does not mean it need not be well-formed and valid if the processor
requires it.
In some situations the value of a property is not sufficiently
specified by a simple literal. For example, properties such as
height or weight would require more than a string to fully specify
them:
Example
<head>
<meta property="height">87</meta>
</head>
In cases such as this it is not clear whether we are dealing with
metres, miles or microns. Whilst it's certainly possible to add the
units to the literal itself there will be situations where this is
not possible, and so the unit should be specified with
datatype In this example we use the XML Schema type for date:
Example
<head>
<meta property="created" datatype="xsd:date">2004-03-22</meta>
</head>
There will be situations when a string literal is not suitable as
the value of a property. In the example just given there would be no
way to know which 'Mark Birbeck' we are referring to. This might not
be a problem when documents are only used within one company, but
this becomes a big problem when documents are used across the
internet.
When we need to provide a unique identifier for the value of a
property we use
link.
link identifies a relationship between one resource and
another, and uses
rel to indicate the nature of this relationship. In addition
href contains the URI that is being used to uniquely identify
the item being related to. For example:
Example
<head>
<link rel="author"
href="http://example.com/people/MarkBirbeck/654" />
</head>
Note that just because we are using URIs as unique identifiers
doesn't mean that navigating to this URI with a web browser would
yield anything useful. This is perhaps easier to see with the
following example:
Example
<head>
<link rel="source" href="urn:isbn:0140449132" />
</head>
22.4.3. Making
Use of External Lists of Properties
Best practice for specifying metadata is to try as much as
possible to make use of common property names. This can often be
achieved by using lists in use by other document authors within a
similar field. There are many such lists for different sectors and
industries, but for our examples here we will use Dublin Core[DCORE].
To replace the term 'author' with the more widely used Dublin
Core term 'creator', we would need to not only substitute 'creator'
for 'author', but also to indicate which list we are using. We
achieve the latter by using XML namespaces:
Example
<head xmlns:dc="http://purl.org/dc/elements/1.1/">
<meta property="dc:creator">Mark Birbeck</meta>
</head>
Now we have stated that:
Example
this document has a property called 'creator' (which comes
from a library of properties called the Dublin Core) and the
value of that property is the literal "Mark Birbeck".
22.5. Properties of
Other Resources
While it is common to create properties and values that say
something about the document that contains them, there is often a
need to add metadata that refers only to a section of the document,
or to some external resource. This is achieved by using
about, which can be present on
meta and
link.
22.5.1.
Resources Within the Containing Document
A quote might be attributed as follows:
Example
<html xmlns:dc="http://purl.org/dc/elements/1.1/">
<head>
<link about="#q1" rel="dc:source" href="urn:isbn:0140449132" />
</head>
<body>
<blockquote id="q1">
<p>
'Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!'
</p>
</blockquote>
</body>
</html>
Note that the absence of
about does not always mean that the metadata refers to the
containing document. If the element containing metadata is a child
of
head, then it does relate to the document, and so the following
mark-up:
Example
<head xmlns:dc="http://purl.org/dc/elements/1.1/">
<meta property="dc:creator">Mark Birbeck</meta>
</head>
can be regarded as a shorthand for this:
Example
<head xmlns:dc="http://purl.org/dc/elements/1.1/">
<meta about="" property="dc:creator">Mark Birbeck</meta>
</head>
22.5.2.
External Resources
There is also a need to add metadata to a document that concerns
an item that is external to the document. As before we use
about, but this time we should provide an absolute or relative
URI, rather than just a fragment identifier.
An example might be to say that the copyright of some document is
owned by a company, and further, that the company is located in
London:
Example
<head xmlns:dc="http://purl.org/dc/elements/1.1/">
<link rel="dc:copyright"
href="http://example.com/company/BBC/6" />
<meta about="http://example.com/company/BBC/6"
property="dc:location">London</meta>
</head>
22.6. Chaining
Metadata
Metadata that is relevant to a resource referred to by a
link can be placed inside the
link element with no
about. Our previous example could be re-written as follows:
Example
<head xmlns:dc="http://purl.org/dc/elements/1.1/">
<link rel="dc:copyright"
href="http://example.com/company/BBC/6">
<meta property="dc:location">London</meta>
</link>
</head>
There is no limit to the depth of this nesting.
What attribute
is this?
There is no resource attribute any longer. What was it changed
to in this context?
If resource is omitted from a
link then the nested metadata is still legitimate, it simply
relates to an anonymous resource. For example, we might want to say
that the 'mother tongue' of the author of Crime and Punishment
is Russian, without saying anything further about the author:
Example
<html xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:con="http://example.org/terms/" >
<head />
<body>
<blockquote id="q1">
<link rel="dc:source" href="urn:isbn:0140449132">
<link rel="dc:creator">
<meta property="con:motherTongue">rus</meta>
</link>
</link>
<p>
'Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!'
</p>
</blockquote>
</body>
</html>
When reading this metadata, the anonymous resource can be thought
of simply as 'something'. This mark-up means:
- The quote has a source of Crime and Punishment.
- Crime and Punishment has a property of 'creator'
(from the Dublin Core taxonomy), and the value of that property
is something.
- The something that is the author of Crime and
Punishment has a property of 'mother tongue' (from the SWAP
contacts taxonomy), and the value of that Property is "Russian".
Note however that while placing further elements inside
meta is structurally valid, it does not mean the same thing as
the example we have just given, since the content of
meta is an XML literal. The following:
Example
<blockquote id="q1">
<link about="#q1" rel="dc:source" href="urn:isbn:0140449132">
<meta property="dc:creator">
<meta property="con:motherTongue">rus</meta>
</meta>
</link>
<p>...</p>
</blockquote>
means that:
- the quote has a source of Crime and Punishment.
- Crime and Punishment has a property of 'creator'
(from the Dublin Core taxonomy), and the value of that property
is the XML literal "<meta
property="con:motherTongue">rus</meta>".
23. XHTML Metainformation Attributes Module
This section is normative.
The Metainformation Attributes Module defines the
Metainformation attribute collection. This collection allows
elements to be annotated with metadata throughout an
XHTML-family document.
23.1. Metadata Attribute Collection
-
about =
URI
- This attribute specifies which resource has a specified
property.
If this attribute is not present then the resource being
referred to by a
property attribute on the same element is decided as
follows:
- If the element on which the other metadata
attributes are attached is a child of a
link then the metadata inferred by the element
concerns the URI referred to in the
link.
- Otherwise, the metadata inferred by the element
concerns the current document.
Example
<meta about="http://www.example.com/" property="dc:created">2004-03-20</meta>
-
content =
CDATA
- This attribute specifies the metadata associated with an
element. If not specified, then the metadata for an element
is its content.
Example
<meta about="http://www.example.com/" property="dc:created" content="2004-03-20"/>
-
datatype =
QName
- This attribute defines the datatype of the content
metadata of the element. If the attribute is not specified,
then the default value is
string as defined by [XMLSCHEMA].
Example
<meta about="http://www.example.com/" property="dc:created" datatype="xsd:date">2004-03-20</meta>
-
property =
QName
- This attribute indicates which property is being defined
by the element. If it is not specified, the property is
reference.
Example
<meta about="http://www.example.com/" property="dc:creator">John Smith</meta>
Authors may use the following properties, listed here
with their conventional interpretations.
User agents, search engines, etc. are free to interpret
these properties as necessary.
Users may extend this collection of relationships.
However, extensions must be defined in their own namespace,
and the relationship names must be referenced in documents
as qualified names (e.g., dc:creator for the Dublin Core
"creator" relationship).
Note that in order to reference relationship definitions
via QName, their namespace must be defined via an xmlns
attribute on the root element of the document:
Example
<html .... xmlns:dc="http://purl.org/dc/elements/1.1/">
- description
- Gives a description of the resource.
- generator
- Identifies the software used to generate the
resource.
- keywords
- Gives a comma-separated list of keywords describing
the resource.
- robots
- Gives advisory information intended for automated
web-crawling software. This specification does not
define values for this property.
- title
- Specifies a title for the resource.
Note that previous versions of XHTML included an
author property; this has now been replaced with the
Dublin Core creator property.
Note that:
Example
<head>
<title>My Life and Times</title>
is just a shorthand for:
Example
<head>
<meta property="title">My Life and Times</meta>
Note that the
title attribute which is available on all XHTML2
elements, is just a shorthand for a common case:
Example
<a href="Jakob.html" title="Author biography">Jakob Nielsen</a>'s Alertbox for January 11, 1998
is equivalent to:
Example
<meta about="#jakob" property="title">Author biography</meta>
<a href="Jakob.html" id="jakob">Jakob Nielsen</a>'s Alertbox for January 11, 1998
Note that this allows you to specify richer, marked-up
text for a title when needed.
-
rel =
QName
- This attribute describes the relationship between the
resource specified by the
about attribute (or its default value) and the resource
referred to by the
href attribute.
Example
<link href="top.html" rel="contents"/>
This example defines a link to a table of contents for
the current document.
Example
<link href="doc.ps"
rel="alternate"
media="print"
hreftype="application/postscript" />
This example defines a link to an alternate version of
the document especially suited to printing.
Authors may use the following relationship names, listed
here with their conventional interpretations.
User agents, search engines, etc. may interpret these
relationships in a variety of ways. For example, user agents
may provide access to linked documents through a navigation
bar.
Users may extend this collection of relationships.
However, extensions must be defined in their own namespace,
and the relationship names must be referenced in documents
as qualified names (e.g., dc:creator for the Dublin Core
"creator" relationship).
Note that in order to reference relationship definitions
via QName, their namespace must be defined via an xmlns
attribute on the root element of the document:
Example
<html .... xmlns:dc="http://purl.org/dc/elements/1.1/">
- alternate
- Designates alternate versions for the document. When
used together with the
hreflang attribute, it implies a translated version
of the document. When used together with the
hrefmedia attribute, it indicates a version intended
for that type of device.
- start
- Refers to the first resource in a collection of
resources. A typical use case might be a collection of
chapters in a book.
- next
- Refers to the next resource (after the current one)
in an ordered collection.
- prev
- Refers to the previous resource (before the current
one) in an ordered collection.
- up
- Refers to the resource "above" in a hierarchically
structured set.
- contents
- Refers to a resource serving as a table of contents.
- index
- Refers to a resource providing an index.
- glossary
- Refers to a resource providing a glossary of terms.
- copyright
- Refers to a copyright statement for the resource.
- chapter
- Refers to a resource serving as a chapter in a
collection.
- section
- Refers to a resource serving as a section in a
collection.
- subsection
- Refers to a resource serving as a subsection in a
collection.
- appendix
- Refers to a resource serving as an appendix in a
collection.
- help
- Refers to a resource offering help (more
information, links to other sources of information,
etc.)
- bookmark
- Refers to a bookmark. A bookmark is a link to a key
entry point within an extended document. The
title attribute may be used, for example, to label
the bookmark. Note that several bookmarks may be defined
for a document.
- meta
- Refers to a resource that provides metadata, for
instance in RDF.
- icon
- Refers to a resource that represents an icon.
- p3pv1
- Refers to a P3P Policy Reference File. See [P3P].
- profile
- Refers to a resource that defines relationships or
provides metadata, for instance in RDF. User agents may
use this URI in two ways:
- As a globally unique name. User agents may be
able to recognize the name (without actually
retrieving the profile) and perform some activity
based on known conventions for that profile. For
instance, search engines could provide an interface
for searching through catalogs of XHTML documents,
where these documents all use the same profile for
representing catalog entries.
- As a link. User agents may dereference the URI
and perform some activity based on the actual
definitions within the profile (e.g., authorize the
usage of the profile within the current XHTML
document). This specification does not define
formats for profiles.
This example refers to a hypothetical profile that
defines useful properties for document indexing. The
properties defined by this profile -- including
"author", "copyright", "keywords", and "date" -- have
their values set by subsequent
meta declarations.
Example
<html ... xmlns:mp="http://www.example.com/profiles/rels">
<head>
<title>How to complete Memorandum cover sheets</title>
<link rel="profile" href="http://www.example.com/profiles/slideshow" />
</head>
<body>
<div class="slide">
some slide content...
</div>
</body>
.
- role
- Indicates the purpose of the resource. For some
possible values, see
the Role Attribute module.
- cite
- Refers to a resource that defines a citation (see
cite) .
Relationship 'required'
Linktype 'required'
-
rev =
QName
- This attribute is used to describe the relationship of a
reverse link from the anchor specified by the resource
attribute to the current document. For a list of
relationship names, see the
rel attribute.
Implementation:
RELAX NG
23.2. Meta and
RDF
The metadata attributes can be used to generate RDF
statements. The attributes
rel,
rev and
property represent predicates. The predicate is
obtained by concatenating the namespace URI and the local part
of the Qname of the attribute value. For attribute
rel, the subject is the
about property, and the object is the value of the
href attribute; for attribute
rev, the subject and object roles are reversed. For
attribute
property, the subject is the
about property, and the object is the string literal in the
content attribute, or otherwise the XML literal that is the
content of the element, decorated as necessary with the value of
the
datatype attribute.
23.3. Metadata
as Content
One use of the metadata attributes is with elements that
represent document content, since the same string literal can be
used to specify both document content, and metadata.
For example, articles often have the following repetitive
structure, where the same values are used for metadata
properties and actual content rendered to the reader:
Example
<html xmlns="http://www.w3.org/2002/06/xhtml2/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<head>
<title>... title ...</title>
<meta property="dc:date">March 23, 2004</meta>
<meta property="dc:title">
High-tech rollers hit casino for £1.3m
</meta>
<meta property="dc:creator">Steve Bird</meta>
</head>
<body>
...
<span class="date">March 23, 2004</span>
<span class="headline">
High-tech rollers hit casino for £1.3m
</span>
<span class="byline">By Steve Bird</span>
<span class="standfirst">
Word of a hand-held device which can beat the roulette wheel
has gambling bosses quaking
</span>
...
<p>...</p>
</body>
</html>
By making use of the meta attributes this can be shortened to
the following:
Example
<html xmlns="http://www.w3.org/2002/06/xhtml2/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<head>
<title>... title ...</title>
</head>
<body>
...
<span property="dc:date"
class="date">
March 23, 2004
</span>
<span property="dc:title"
class="headline">
High-tech rollers hit casino for £1.3m
</span>
By <span property="dc:creator"
class="byline">Steve Bird</span>
<span class="standfirst">
Word of a hand-held device which can beat the
roulette wheel has gambling bosses quaking
</span>
...
<p>...</p>
</body>
</html>
This is often easier to maintain since an author editing
their document is at the same time editing the metadata.
23.4. Mapping
Lexical Content
Another use for the meta attributes on other mark-up elements
is to provide a normalized value for some text. This is
especially important to certain types of consumers of metadata,
such as search engines.
For example, the following article would be difficult to
locate:
Example
Tomorrow the <span>Prime Minister</span> is expected to fly to ...
However, by using
href and
content we can indicate exactly which Prime Minister is
being referred to, and when the journey is due to take place:
Example
<span content="2004-03-20">Tomorrow</span> the
<span href="http://example.com/people/TonyBlair/1">Prime Minister</span>
is expected to fly to ...
Note that if no
property is present then the example just given is
equivalent to:
Example
<span property="reference"
content="2004-03-20">
Tomorrow
</span>
the <span property="reference"
href="http://example.com/people/TonyBlair/1">
Prime Minister
</span>
is expected to fly to ...
Mark Birbeck on XHTML 2 - Glazblog
<meta property="email:From"><name>John
Doe</name><address>jdoe@machine. example</address></meta>.
Wednesday 16 March 2005 at 08:30, by glandium :: site ::
# ...
glazman.org/weblog/dotclear/index.php?2005/03/16/937-mark-birbeck-on-xhtml-2
- 30k -
Cached -
Similar pages |
Mark Birbeck on XHTML 2
Mark, an Invited Expert to the HTML WG, has written
a short essay to explain why, in his thought, XHTML 2.0
is to become a new lingua franca. As you probably know if
you often read this blog, I happen to disagree but that's
not the point of my comment today. I just wanted to take his
code snippet example and comment on it:
<html
xmlns="http://www.w3.org/2002/06/xhtml2/"
xmlns:email="http://www.faqs.org/rfcs/rfc2822.html#"
>
<head>
<meta property="email:From">John Doe <jdoe@machine.example></meta>
<meta property="email:To">Mary Smith <mary@example.net></meta>
<meta property="email:Subject">Saying Hello</meta>
<meta property="email:Date">Fri, 21 Nov 1997 09:55:06-0600</meta>
<meta property="email:Message-ID"><1234@local.machine.example></meta>
<title>An email from John to Mary saying 'hello'</title>
<head>
<body>
This is a message just to say hello.
So, "Hello".
<body>
<html>
I can see two design flaws in the simple example above:
- We don't need the head and body elements. They are
useless. The metadata elements apply to the document. So
elements
title and meta should
just apply to the parent element, and the document
itself if the parent element is the root of the
document. Samething for the body. An element is a
"content container" (if you allow that neologism) or
not. We don't need the body. Getting rid of the body
will help solving the big problem of "background of the
body" vs. "background of the document" vs. "background
of the canvas".
- Since semantics is the word in everyone's mouth
these days, plain text should not be allowed directly
inside the
body element.
So we should really have here:
<html xmlns="http://www.w3.org/2002/06/xhtml2/"
xmlns:email="http://www.faqs.org/rfcs/rfc2822.html#">
<meta property="email:To">Mary Smith <mary@example.net></meta>
<meta property="email:Subject">Saying Hello</meta>
<meta property="email:Date">Fri, 21 Nov 1997 09:55:06-0600</meta>
<meta property="email:Message-ID"><1234@local.machine.example></meta>
<title>An email from John to Mary saying 'hello'</title>
<p>This is a message just to say hello.
So, "Hello".</p>
<html>
And I have two extra comments:
- this example being about email, the visible line
break between the two lines of text in the body would
need a <br /> or such to be materialized on the
recipient's side.
- the original example had an extra erroneous > on the
Email:From line. I removed it above.
Richard Soderberg posted the following email to the
geowanking list on Wednesday. It’s a nice review of the
various geo-syntaxes currently in use.
If you know of any
others, please let me know.
What all is out there currently, and what’s the
conglomerate of them all look like for a given page?
The conglomerate of <HEAD> modifications from what I’ve
looked at so far:
<head profile="http://geotags.com/geo">
<meta name="ICBM” content="44.07,-123.08″ />
<meta property="geo:lat">46.1</meta>
<meta property="geo:long">124</meta>
<meta name="geo.position” content="44.07;-123.08″>
<meta name="geo.region” content="US-OR">
<meta name="geo.placename” content="Eugene">
</head>
There’s only one way I’ve found, so far, to associate
the data with a given container element:
<span style="display:none”
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<geo:lat>46.1</geo:lat><geo:long>124</geo:long>
</span>
Reading an XHTML specification, I find that <meta
property> can be used with <link rel="profile"> to
indicate the definitions of certain metadata attributes
such as geo:lat, geo:long, and geo:alt. As such, the
following syntax should be:
(a) XHTML compliant
(b) human and X?HTML-editor readable
© easy to detect with existing HTML spiders
(d) not limiting future development of shapes and so on.
I think it’d be a worthy successor to the ICBM
header, even if it’s slightly larger in byte-size. That
said, it may not serve the one-tag desires or the
per-item desires. I submit this for discussion.
<head>
<link rel="profile”
href="http://www.w3.org/2003/01/geo/wgs84_pos#">
<meta property="geo:lat">46.1</meta>
<meta property="geo:long">124</meta>
</head>
- R.
GeoURL:
- To tag an HTML document, put this in the HEAD
block:
<meta name="ICBM” content="44.07,-123.08″ />
Map Bureau:
- To tag an HTML document, put this in the HEAD
block:
<meta property="geo:lat">46.1</meta>
<meta property="geo:long">124</meta>
- To tag an HTML container element, include the
following block:
<span style="display:none” xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<geo:lat>46.1</geo:lat><geo:long>124</geo:long>
</span>
Blogmapper:
- To tag an HTML container element, include the
following block:
<span style="display:none”
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<geo:lat>46.1</geo:lat><geo:long>124</geo:long>
</span>
Geotags:
- To tag an HTML document, put this in the HEAD
block:
<head profile="http://geotags.com/geo">
<meta name="geo.position” content="44.07;-123.08″>
<meta name="geo.region” content="US-OR">
<meta name="geo.placename” content="Eugene">
Locative:
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:rdfs="http://www.w3.org/2001/02/rdf-schema#”
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#”
xmlns:dc="http://purl.org/dc/elements/1.1/”
xmlns:locative="http://locative.net/etcon2004/loc#”
xmlns:media="http://purl.org/dc/dcmitype/”
>
<locative:Packet>
<dc:coverage>
<geo:Point>
<geo:long>-0.0104</geo:long>
<geo:lat>51.5722</geo:lat>
</geo:Point>
</dc:coverage>
<locative:media>
<media:Image
rdf:about="http://iconocla.st/photo/2003/10/12/img_0299-m.jpg”
dc:format="image/jpeg"/>
</locative:media>
<rdfs:seeAlso
rdf:resource="http://iconocla.st/photo/2003/10/12/img_0299.html"/>
</locative:Packet>
</rdf:RDF>