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

[Joe Hildebrand <[e-mail]>]

On 3/30/10 6:55 AM, "Simon Perreault" <[e-mail]> wrote:

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

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

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

Yes.

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

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

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

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

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

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