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

[Joe Hildebrand <[e-mail]>]

On 3/24/10 10:36 AM, "Simon Perreault" <[e-mail]> wrote:

> 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.

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