One document matched: draft-ietf-vcarddav-vcardxml-03.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc rfcedstyle="yes" ?>
<?rfc rfcprocack="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?><!-- default = 3 -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-vcarddav-vcardxml-03" category="std">
<front>
<title abbrev="vCard XML">vCard XML Representation</title>
<author initials="S." surname="Perreault" fullname="Simon Perreault">
<organization>Viagénie</organization>
<address>
<postal>
<street>2600 boul. Laurier, suite 625</street>
<city>Québec</city>
<region>QC</region>
<code>G1V 4W1</code>
<country>Canada</country>
</postal>
<phone>+1 418 656 9254</phone>
<email>simon.perreault@viagenie.ca</email>
<uri>http://www.viagenie.ca</uri>
</address>
</author>
<date year="2010"/>
<area>Applications</area>
<keyword>vcard</keyword>
<abstract>
<t>This document defines the XML schema of the vCard data format.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>vCard <xref target="I-D.ietf-vcarddav-vcardrev"/> is a data
format for representing and exchanging information about individuals.
It is a text-based format (as opposed to a binary format). This
document defines an XML representation for vCard. The underlying data
structure is exactly the same, enabling a 1-to-1 mapping between the
original vCard format and the XML representation. The XML formatting may
be preferred in some contexts where an XML engine is readily available
and may be reused instead of writing a stand-alone vCard parser.</t>
<t>Earlier work on an XML format for vCard was started in 1998 by Frank
Dawson <xref target="I-D.dawson-vcard-xml-dtd"/>. Sadly it did not take
over the world.</t>
</section>
<section title="The Schema">
<t>The schema is expressed in the RELAX NG language <xref
target="relaxng"/><xref target="relaxng-compact"/> and is found in
<xref target="schema"/>.</t>
</section>
<section title="Example: Author's XML vCard">
<figure>
<artwork>
<![CDATA[%%simon.xml%%]]>
</artwork>
</figure>
</section>
<section title="Design Considerations">
<t>The general idea is to map vCard parameters, properties, and value
types to XML elements. For example, the "FN" property is mapped to the
"fn" element. That element in turn contains a text element whose
content corresponds to the vCard property's value.</t>
<t>vCard parameters are also mapped to XML elements. They are contained in
the <parameters> element, which is contained in property elements.
For example, the "TYPE" parameter applied to the "TEL" property would
look like the following in XML:</t>
<figure>
<artwork><![CDATA[
<tel>
<parameters>
<type>voice</type>
<type>video</type>
</parameters>
<uri>tel:+1-555-555-555</uri>
</tel>
]]></artwork>
</figure>
<t>Parameters taking a list of values are simply repeated multiple times,
once for each value in the list.</t>
<t>Properties having structured values (e.g. the "N" property) are
expressed by XML element trees. Element names in that tree (e.g.
"surname", "given", etc.) do not have a vCard equivalent since they
are identified by position in plain vCard.</t>
<t>Line folding is a non-issue in XML. Therefore, the mapping from vCard
to XML is done after the unfolding procedure is carried out.
Conversely, the mapping from XML to vCard is done before the folding
procedure is carried out.</t>
<section title="Extensibility">
<t>The original vCard format is extensible. New properties, parameters,
data types and values (collectively known as vCard objects) can be
registered from IANA. It is expected that these vCard extensions will
also specify extensions to the XML format described in this document.
This is not a requirement: a separate document may be used instead.</t>
<t>Unregistered extensions (i.e. those starting with "X-" and
"VND-...-") can be expressed in XML by making use of XML namespaces.
They simply correspond to elements outside of the core namespace. For
example:</t>
<figure>
<artwork><![CDATA[
<ext:my-prop
ext:xmlns="http://example.com/extensions/my-vcard">
<parameters>
<pref>1</pref>
</parameters> <!-- Core vCard elements -->
<text>value goes here</text> <!-- are still accessible -->
</ext:my-prop>
]]></artwork>
</figure>
<t>Note that extension elements do not need the "X- or "VND-" prefix in
XML. The XML namespace mechanism is sufficient.</t>
<t>A vCard XML parser MUST ignore XML elements and attributes for which
it doesn't recognize the expanded name. The normal behaviour of
ignoring XML processing instructions whose target is not recognized
MUST also be followed.</t>
<t>In the original vCard format, the "VERSION" property was mandatory and
played a role in extensibility. In XML, this property is absent. Its
role is played by the vCard core namespace identifier, which includes
the version number. vCard revisions will use a different
namespace.</t>
<t>Parameters containing a list of values are expressed using a list of
elements in XML (e.g. the <type> element).</t>
</section>
<section title="Limitations">
<t>The schema does not validate the cardinality of properties. This is a
limitation of the schema definition language. Cardinalities of the
original vCard format <xref target="I-D.ietf-vcarddav-vcardrev"/>
MUST still be respected.</t>
<t>Some constructs (e.g. value enumerations in type parameters) have
additional ordering constraints in XML. This is a result of
limitations of the schema definition language and the order is
arbitrary. The order MUST be respected in XML for the vCard to be
valid. However, reordering as part of conversion to or from plain
vCard MAY happen.</t>
</section>
</section>
<section title="Format Conversions">
<t>When converting from XML vCard (this specification) to plain-text vCard
<xref target="I-D.ietf-vcarddav-vcardrev"/>, the following rules
apply:</t>
<t>
<list style="symbols">
<t>Properties in the vCard 4 namespace:</t>
<t>
<list style="symbols">
<t>If the converter knows of a specific plain-text representation
for this property, it uses it. For example, the <adr>
element corresponds to the "ADR" property, which is encoded
using comma-separated lists separated by semi-colons.</t>
<t>Otherwise, the property name is taken from the element name,
property parameters are taken from the <parameters>
element, and the content of the property is taken from the
content of the value element. If the property element has
attributes or contains other XML elements, they are dropped.</t>
<t>If a standard property's XML element contains XML elements and
attributes for which the converter doesn't recognize the
expanded name, they are dropped. Therefore, it is RECOMMENDED to
limit extensions to the property level to ensure that all data
is preserved intact in round-trip conversions.</t>
</list>
</t>
<t>Properties in other namespaces are wrapped as-is inside an "XML"
property.</t>
</list>
</t>
<t>When converting from plain-text vCard <xref
target="I-D.ietf-vcarddav-vcardrev"/> to XML vCard (this
specification), the following rules apply:</t>
<t>
<list style="symbols">
<t>The content of "XML" properties is converted as-is to XML.</t>
<t>Properties for which the converter knows of a specific XML
representation use it. For example, the "ADR" property is
represented using the <adr> element and related
sub-elements.</t>
<t>Other properties are converted to XML in the following way:</t>
<t>
<list style="symbols">
<t>The XML namespace of the property element is set to the vCard 4
namespace.</t>
<t>The name of the property element is set to that of the
property.</t>
<t>If the property has attributes, they get translated as-is into
sub-elements of the <parameters> element</t>
<t>The property element contains a single <text> element
whose content is copied as-is from the property's value.</t>
</list>
</t>
</list>
</t>
<t>For example, these two vCards are equivalent:</t>
<figure>
<artwork><![CDATA[
<xml version="1.0">
<vcards xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<vcard>
<fn><text>J. Doe</text></fn>
<n>
<surname><text>Doe</text></surname>
<given><text>J.</text></given>
<prefix/>
<suffix/>
</n>
<x-file>
<parameters><type>image/jpeg</type></parameters>
<text>alien.jpg</text>
</x-file>
<a xmlns="http://www.w3.org/1999/xhtml"
href="http://www.example.com">My web page!</a>
</vcard>
</vcards>
</xml>
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
BEGIN:VCARD
VERSION:4.0
FN:J. Doe
N:Doe;J.;;
X-FILE;TYPE=image/jpeg:alien.jpg
XML:<a xmlns="http://www.w3.org/1999/xhtml"\n
href="http://www.example.com">My web page!</a>
END:VCARD
]]></artwork>
</figure>
</section>
<section title="Security Considerations">
<t>All the security considerations applicable to plain vCard <xref
target="I-D.ietf-vcarddav-vcardrev"/> are applicable to this document
as well.</t>
</section>
<section title="IANA Considerations">
<section title="Registration of the XML Namespace">
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:vcard-4.0</t>
<t hangText="Registrant Contact:">Simon Perreault
<simon.perreault@viagenie.ca></t>
<t hangText="XML:">None. Namespace URIs do not represent an XML
specification.</t>
</list>
</t>
</section>
</section>
<section title="Acknowledgements">
<t>Thanks to the following people for their input:</t>
<t>Alexey Melnikov, Barry Leiba, Cyrus Daboo, Joe Hildebrand, Joseph
Smarr, Marc Blanchet, Peter Saint-Andre, Robins George, Zahhar Kirillov,
Zoltan Ordogh.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.draft-ietf-vcarddav-vcardrev-11"?>
<?rfc include="reference.relaxng"?>
<?rfc include="reference.relaxng-compact"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.draft-dawson-vcard-xml-dtd-03"?>
</references>
<section title="Relax NG Schema" anchor="schema">
<figure>
<artwork>
<![CDATA[%%vcard.rnc%%]]>
</artwork>
</figure>
</section>
<section
title="Change Log (to be removed by RFC Editor prior to publication)"
anchor="changelog">
<section title="Changes in -03">
<t>
<list style="symbols">
<t>Created "Format Conversions" section.</t>
<t>Turned more <type> parameter values into plain text.</t>
<t>Removed need for empty value elements in components.</t>
<t>Wrapped value of <sex>, <class>, and <kind> in
value elements.</t>
</list>
</t>
</section>
<section title="Changes in -02">
<t>
<list style="symbols">
<t>Synchronized with draft-ietf-vcarddav-vcardrev-10.</t>
<t>Turned <type> parameter values into plain text.</t>
<t>Moved the "XML" property to vCard base.</t>
<t>Changed title to avoid confusion with XML Schema.</t>
<t>Added prefixes "value-", "param-", and "property-" in schema.</t>
<t>Better language for specifying what a parser must ignore.</t>
</list>
</t>
</section>
<section title="Changes in -01">
<t>
<list style="symbols">
<t>Synchronized with draft-ietf-vcarddav-vcardrev-09.</t>
<t>Added the <vcards> element to allow multiple vCards in a
single XML file.</t>
<t>Created the <parameters> container element.</t>
<t>Use text value for enumeration in <class> element.</t>
<t>Created the "XML" vCard property.</t>
<t>Added IANA considerations section.</t>
<t>Added security considerations section.</t>
</list>
</t>
</section>
<section title="Changes in -00">
<t>
<list style="symbols">
<t>Same as draft-perreault-vcarddav-vcardxml-02.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:22:18 |