Subject: [VCARDDAV] How to encode X-Properties in XML?

From: Simon Perreault <[email-masked]>
Date: Mon, 08 Mar 2010 10:10:13 -0500

WG,

The main open issue we have for vCard XML is that of encoding 
X-Properties in XML. vCard uses X- for unregistered extensions, while 
vCard XML uses XML namespaces. It's not clear how to automatically 
convert from one to another.

A proposal: Create an XML namespace for X- properties. Put the content 
into a <text> element.

Example:

X-FOO:bar

would translate into:

<foo xmlns="urn:ietf:params:xml:ns:vcard-4.0:xname"><text>bar</text></foo>

We don't need to add anything to the schema since we already specify 
that an XML vCard parser MUST ignore elements in namespaces it doesn't 
recognize. (Maybe we can add text to force it for this namespace.)

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

---

From: Renato Iannella <[email-masked]>
Date: Tue, 9 Mar 2010 16:05:03 +1000

> <foo xmlns="urn:ietf:params:xml:ns:vcard-4.0:xname"><text>bar</text></foo>

Should we be defining namespaces for external properties?

Another option is to say that if you understand X-FOO, then you should also understand what Namespace to use in XML representations (otherwise, why are you translating this to XML ?)

Cheers...  Renato Iannella
NICTA

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 09 Mar 2010 10:39:57 -0500

Hi Simon,

--On March 8, 2010 10:10:13 AM -0500 Simon Perreault 
<[email-masked]> wrote:

> We don't need to add anything to the schema since we already specify that
> an XML vCard parser MUST ignore elements in namespaces it doesn't

The choice we made for icalendar-in-xml was to simply allow the X- 
properties to appear as <x-...> elements in the default "icalendar" 
namespace. It did not seem worthwhile to have a special namespace for those 
as in reality they are processed in exactly the same way as regular 
properties. The key thing is that these elements/properties cannot be 
ignored. They are there for a purpose (be it only "experimental").

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Tue, 09 Mar 2010 10:41:54 -0500

On 2010-03-09 10:39, Cyrus Daboo wrote:
> namespace. It did not seem worthwhile to have a special namespace for
> those as in reality they are processed in exactly the same way as
> regular properties. The key thing is that these elements/properties
> cannot be ignored. They are there for a purpose (be it only
> "experimental").

How do you express that in the schema?

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

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 09 Mar 2010 11:31:26 -0500

Hi Simon,

> How do you express that in the schema?

Actually we did not do that. The problem with X- is the same for VND- and 
new standard properties/parameters too. I think relaxNG has an "anyName" 
option for element names that could be used to represent arbitrary named 
items. There may be a way to utilize that. The question is whether the 
schema will really be used to validate the data. That is hard given the 
ease with which vCard/iCalendar data is itself extensible.

-- 
Cyrus Daboo

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Mar 2010 14:06:01 -0700

On 3/9/10 8:39 AM, Cyrus Daboo wrote:
>> <foo
>> xmlns="urn:ietf:params:xml:ns:vcard-4.0:xname"><text>bar</text></foo>
>>
> namespace. 

IIRC we had some discussion about this around the time of the Stockholm
meeting, starting here:

http://www.ietf.org/mail-archive/web/vcarddav/current/msg01126.html

Joe Hildebrand suggested:

X-FOO:test
VND-BAR:hi

Turning into:

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

Simon said 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>

Joe replied that "pulling random elements into your own namespace is
somewhat odd from an XML standpoint."

I tend to agree. If we're going to be pulling in random elements, I'd
rather do so in a namespace other than the core one (let's have a
namespace that we know is going to be polluted from the start so that we
contain the ugliness).

> It did not seem worthwhile to have a special namespace for

There might be value in doing the same thing as icalendar. Is it really
true that X- and VND data cannot be ignored? Or do we say that a
vCard-xml processor MUST support the urn:ietf:params:xml:ns:vcard-4.0:x
and urn:ietf:params:xml:ns:vcard-4.0:vnd namespaces (but perhaps MAY
treat data qualified by those namespaces differently somehow)?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Mar 2010 10:36:38 -0700

Here's a summary of the hallway discussion on this issue:

The only argument against proposal #2 (<x-foo> and <vnd-123-foo> in the 
vCard namespace) was that it prevents you from having a schema that 
would not accept invalid properties.

However, implementations already need to accept new properties that are 
registered by IANA. These will create new elements in the vCard 
namespace, just like x-props and vendor props. Therefore, the argument 
doesn't apply.

So unless new information is received, I'll go with #2 in the next rev.

Thanks,
Simon

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 29 Mar 2010 22:13:47 -0700

> So unless new information is received, I'll go with #2 in the next rev.

I'm onboard with this approach.  There were a couple more subtleties that
came out of thinking about this some more, that I would like to see captured
in the text.  Most of this has been talked about on the list before, so this
is more in the way of recap:

- In the XML format, any child of <vcard> in the default namespace gets
translated to a text property.  X-, VND-, and
newly-registered-but-not-yet-supported-in-your-software elements all fall
into this category.  Unfortunately, it appears that we need to upcase in the
XML-to-text direction, and downcase in the opposite direction.  Now that
we're in UTF-8, there's a little bit of work to specify these mappings.

- In the XML format, any child of <vcard> in a namespace other than the
default gets turned into XML: in the text format.  Even if it is
standardized.

- In the text format, XML: properties always get directly transliterated
into XML as children of <vcard>.  This means they MUST have a namespace
other than the default.  If they don't, we can specify what happens, but the
list of things I've thought of are: 1) error, and fail translation 2) warn,
and don't copy the XML: property 3) warn, and change the namespace to some
specified warning namespace 4) do 3 silently 5) copy the element as-is.

I don't like 5, because the element won't round-trip back to text format the
same way.  3 or 4 sound fine to me, but I could live with 2 or even 1.

- Text format properties that are not currently in the XML definition (such
as X-, VND-, and new-but-iana-registered) are unlikely to ever have any
interesting structure in XML.  The best we can do is specify syntactic
transformations that survive round trips.  As a consequence, we might
consider suggesting that ALL new properties SHOULD be defined in XML format
going forward, with XML: being their native representation in the text
format.

- Do we specify what happens to \n in text format, when translated?  Does it
stay \n, or get translated to CRLF?  What about wrapped lines?  Do they get
unwrapped?  My preference would be unwrap and translate to \n to CRLF.

-- 
Joe Hildebrand

---

From: Filip Navara <[email-masked]>
Date: Tue, 30 Mar 2010 14:29:44 +0200

On Tue, Mar 30, 2010 at 7:13 AM, Joe Hildebrand <[email-masked]>wrote:
[snip]

> we're in UTF-8, there's a little bit of work to specify these mappings.

The characters in the property name are limited to subset of US-ASCII, so
upper/lower-casing is not a problem.

> default gets turned into XML: in the text format.  Even if it is

If it is standardized as IANA vCard property then it is in the default
namespace.

Best regards,
Filip Navara

---

From: Simon Perreault <[email-masked]>
Date: Tue, 30 Mar 2010 08:55:49 -0500

On 2010-03-30 00:13, Joe Hildebrand wrote:
> - In the XML format, any child of<vcard>  in the default namespace gets
> XML-to-text direction

In text vCard, properties are case-insensitive. So no need to upcase in 
this direction.

But as was already mentioned, property names are limited to
[a-zA-Z0-9-].

> - In the XML format, any child of<vcard>  in a namespace other than the

Right.

> into XML as children of<vcard>.  This means they MUST have a namespace

I'd rather follow Postel's principle.

- On output, the element in XML: MUST have a namespace, and it MUST NOT 
be the vCard 4 namespace.

- On input, the content of the XML: property MUST be interpreted as a 
single XML element.

That's it. Whether implementations output warnings or not is out of 
scope (some could even not have the capability of outputting warnings).

> going forward, with XML: being their native representation in the text

+0.5

The problem is that these new properties would be in the vCard 4 
namespace, and we said that no element in this namespace can appear as 
the content of the XML property.

> unwrapped?  My preference would be unwrap and translate to \n to CRLF.

We have this currently:

                                                               The chunk
       is subject to normal line folding and escaping, i.e. replace all
       backslashes with "\\", then replace all newlines with "\n", then
       fold long lines.

Can you suggest text to be added?

Thanks,
Simon

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 30 Mar 2010 07:48:56 -0700

> But as was already mentioned, property names are limited to

Ah, ok.  Didn't realize those, sorry.

> be the vCard 4 namespace.

Yes.

> - On input, the content of the XML: property MUST be interpreted as a

Some text like this would probably be worth mentioning to those that hadn't
thought of the round-tripping problem:

"Note that if the element is in the vCard 4 namespace (either by having no
namespace declaration, or by having the vCard 4 namespace explicitly
redefined), and the element is inserted into an XML format document, it will
not be possible to regenerate the exact form of the text document from the
XML document."

> the content of the XML property.

No.  I'm suggesting that we put these extensions in a new namespace,
preferably a new namespace per spec that adds 1+ properties.

> Can you suggest text to be added?

Ah, that's in the base spec, and I was looking for it in the XML spec.  The
XML spec has:

   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.

Which is a little unclear with respect to \\, although it can be intuited.

I guess I'm hoping we're going to end up with sections in the XML spec that
talk about how to convert to and from the XML format (with examples).  That
would be an appropriate place to move the text above.  The example should
have one of each of the known edge cases.

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Mar 2010 15:12:47 -0600

>> - On input, the content of the XML: property MUST be interpreted as a

Qualified by what namespace? My sense of the discussion so far is that
the single XML element contained in the "XML:" property MUST have some
namespace.

> No.  I'm suggesting that we put these extensions in a new namespace,

"DAV:" perhaps? ;-)

> preferably a new namespace per spec that adds 1+ properties.

Why are we defining this bucket in the first place? It seems to me that
we want to be encouraging people to use the extensibility they have with
XML, not redefine the "urn:ietf:params:xml:ns:vcard-4.0" namespace by
creating new elements in that namespace outside the schema we've defined.

> have one of each of the known edge cases.

+1 to more examples.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 30 Mar 2010 14:47:56 -0700

> the single XML element contained in the "XML:" property MUST have some

I'm just asking "or else what?"  What are the consequences of being
non-conformant, particularly when it can cause loss of information on
round-trip.

>> No.  I'm suggesting that we put these extensions in a new namespace,

Not funny in several directions at once.  Nicely done.

(Note to those who don't get the important one of the jokes, DAV: is a
prefix, not a namespace.)

> creating new elements in that namespace outside the schema we've defined.

Agree that we should be using XML for extensibility, and agree that we don't
want those elements to go into urn:ietf:params:xml:ns:vcard-4.0.  For
example, draft-daboo-vcard-service-type might use
urn:ietf:params:xml:ns:vcard:service-type.  If that I-D defined multiple
properties, they could all use that namespace URI.  The
...vcard:service-type namespace then becomes the bucket.

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Mar 2010 15:53:41 -0600

On 3/30/10 3:47 PM, Joe Hildebrand wrote:
> I'm just asking "or else what?"  

Just as we Jabberites defined the "urn:xmpp:example" namespace, I
suggest that we define an example namespace in the urn:ietf:* tree and
throw these offenders in there ("urn:ietf:params:xml:ns:example").

> What are the consequences of being

That sounds like an appropriate consequence to me. :)

> ...vcard:service-type namespace then becomes the bucket.

Rightio.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 31 Mar 2010 10:36:40 +0200

On 30.03.2010 23:47, Joe Hildebrand wrote:
> ...

Actually, it's both (*). (Kids, don't do this at home).

Best regards, Julian

(*) I wasn't around back then; I think this was caused by the initial 
WebDAV development overlapping with the design of XML namespaces; there 
are some more funny things in appendices of RFC 2518.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Mar 2010 06:16:15 -0600

> are some more funny things in appendices of RFC 2518.

The same is true of the early Jabber community. We have namespaces like
"jabber:client" and even "vcard-temp"...

http://xmpp.org/extensions/xep-0054.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 31 Mar 2010 10:34:05 -0700

>> Actually, it's both (*). (Kids, don't do this at home).

Oh, yeah. I knew there was something I didn't like in this space.

<D:prop xml:lang="en" xmlns:D="DAV:">...

> "jabber:client" and even "vcard-temp"...

Indeed.  Many well-loved protocols from those days didn't have the best
approaches to namespaces, which provides us all the more incentive to do the
best we can today.

-- 
Joe Hildebrand