Subject: [VCARDDAV] XML extensions

From: Joe Hildebrand <[email-masked]>
Date: Wed, 29 Jul 2009 12:01:42 +0200

We talked about this on the bus last night after the WG meeting.

I'm fine with Pete's approach of a single extension point.  The winning
argument for me was that you would have to start a separate XML parser
instance for each field to go down the path I was thinking of.  The
suggestion would be:

EXTENSIONS;ENCODING=b;TYPE=text/xml:base64(xml)

(on the bus, we said "X-TENSIONS", but that was overly-cute)

Which would then turn into a single XML element <extensions/> that contains
all extended XML properties.  When the extensions element is encoded, it
must be turned into a full document, with an encoding processing instruction
(particularly if you're not encoding in UTF-8), and a namespace declaration:

<?xml version="1.0" encoding="UTF-8"?>
<extensions xmlns="urn:ietf:params:xml:ns:vcard-4.0">
  <my-extension xmlns='urn:example:foo'>
  </my-extension>
</extensions>

When the extensions element is decoded, the resulting infoset is inserted
into the vcardxml; this will have the side-effect of removing the processing
instruction and namespace declaration:

<?xml version="1.0" encoding="UTF-8"?>
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
  <fn><text>Simon Perreault</text></fn>
...
  <extensions>
    <my-extension xmlns='urn:example:foo'>
    </my-extension>
  </extensions>
</vcard>

The PI for encoding is important, but (as always in XML) it's odd that
really only the first two code points ("<?") are used to guess the encoding,
then the guess is double-checked with the encoding declaration is reached.

The extensibility language in vcardrev and vcardxml will need to be updated
to ensure round-tripability.  XML extensions will not solve the problem of
existing X- or VND- fields in the old format, and their mechanical
translation into the XML format.

-- 
Joe Hildebrand

---

From: Simon Perreault <[email-masked]>
Date: Wed, 29 Jul 2009 13:24:24 +0200

> EXTENSIONS;ENCODING=b;TYPE=text/xml:base64(xml)
                                     ^^^^^^^^^^^^

Why is this needed? It would mean that when you decode the base64 (as
indicated by ENCODING=b), you end up with base64 data, which you decode
again, and then you have text/xml, right?

(I couldn't find a definition of what it actually means.)

> (on the bus, we said "X-TENSIONS", but that was overly-cute)

You have exceeded your cleverness quota for the day. Please report to
secretariat ASAP.

>     <my-extension xmlns='urn:example:foo'>

Why is the extensions element needed here? There can't be name clashes
anyway because each extension is in its own XML namespace.

> then the guess is double-checked with the encoding declaration is reached.

Just use the charset MIME parameter in the TYPE property parameter:

EXTENSIONS;ENCODING=b;TYPE="text/xml;charset=UTF-8":...

> translation into the XML format. 

Agreed.

+1

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 29 Jul 2009 14:10:45 +0200

>> EXTENSIONS;ENCODING=b;TYPE=text/xml:base64(xml)

That was just shorthand for "the base64-encoded XML".  A real example might
have been:

EXTENSIONS;ENCODING=b;TYPE="text/xml;charset=UTF-8":PGV4dGVuc2lvbnMgeG1sbnM9
InVybjppZXRmOnBhcmFtczp4bWw6bnM6dmNhcmQtNC4wIj4KICA8bXktZXh0ZW5zaW9uIHhtbG5z
PSd1cm46ZXhhbXBsZTpmb28nPgogIDwvbXktZXh0ZW5zaW9uPgo8L2V4dGVuc2lvbnM+

> anyway because each extension is in its own XML namespace.

The idea is to ensure that I only ever have to spin up a single XML parser
if I'm dealing with the original format.  If all of the XML extensions are
collected into a single property, it is easier to achieve that goal.

> EXTENSIONS;ENCODING=b;TYPE="text/xml;charset=UTF-8":...

+1.  See example above.

>> translation into the XML format.

What about:

X-FOO:test
VND-BAR:hi

Turning into:

<x name='FOO'><text>test</text></x>
<vnd name='BAR'><text>hi</text></vnd>
 
-- 
Joe Hildebrand

---

From: Simon Perreault <[email-masked]>
Date: Wed, 29 Jul 2009 14:25:23 +0200

By the way, thanks a lot for sending text. It will make things much easier.

> PSd1cm46ZXhhbXBsZTpmb28nPgogIDwvbXktZXh0ZW5zaW9uPgo8L2V4dGVuc2lvbnM+

Aahh! I was being slow.

> collected into a single property, it is easier to achieve that goal.

I understand why the multiple XML-encoded properties need to be wrapped
in a single element for the value of the EXTENSIONS property. But that
wrapper could be discarded once the properties are placed in a vCard
context.

This would ensure similar treatment for extension and core properties
(e.g. you could use core properties in the EXTENSIONS property).

> <vnd name='BAR'><text>hi</text></vnd>  

We could instead make use of XML namespaces.

<foo xmlns="urn:ietf:params:xml:ns:vcard-4.0:x"><text>test</text></x>
<bar xmlns="urn:ietf:params:xml:ns:vcard-4.0:vnd:bar"><text>hi</text></bar>

(The actual version of vcard would be determined on the fly from the
VERSION property.)

And I'm not sure we should be using the <text> element at all. It would
be kind of lying. We don't really know if it's text or a date or
whatever. So how about we use another tag, e.g. <any>?

If we encounter an XML-based extension (i.e. an element in a different
namespace), we might map it using the EXTENSIONS property. What about:

<blah xmlns='foo'>...</blah>

Turning into:

EXTENSIONS;ENCODING=b;TYPE=text/xml:base64(<blah xmlns='foo'>...</blah>)

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 29 Jul 2009 15:31:42 +0200

> wrapper could be discarded once the properties are placed in a vCard

The extensions element could definitely be removed in the XML version.  But
translation would be easier to implement if it was there.

> (The actual version of vcard would be determined on the fly from the

Pulling random elements into your own namespace is somewhat odd from an XML
standpoint.  

> whatever. So how about we use another tag, e.g. <any>?

I figured you would only use <text/> if you could figure out that the value
was text, or use the value of the VALUE parameter.

I still don't like the use of the <text/> element in general, since it
doesn't describe the thing that it holds semantically, but rather specifies
the syntax.

> EXTENSIONS;ENCODING=b;TYPE=text/xml:base64(<blah xmlns='foo'>...</blah>)

Then there will be multiple extension properties.  If I want to look for
*mine*, I have to create a separate XML parser instance for EACH extension.

-- 
Joe Hildebrand

---

From: Simon Perreault <[email-masked]>
Date: Wed, 29 Jul 2009 15:49:03 +0200

> *mine*, I have to create a separate XML parser instance for EACH extension.

I'm sorry, I should have written this instead:

EXTENSIONS;ENCODING=b;TYPE=text/xml:base64(<extensions><blah
xmlns='foo'>...</blah></extensions>)

Simon

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 29 Jul 2009 15:52:23 +0200

> xmlns='foo'>...</blah></extensions>)

Fine, then the only issue is one of ease of implementation.  Gathering up
the extensions is easier if they're all in a container.

Note: you'll still want a namespace declaration on the extensions element.

-- 
Joe Hildebrand