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

[Peter Saint-Andre <[e-mail]>]

On 3/30/10 8:48 AM, Joe Hildebrand wrote:
> On 3/30/10 6:55 AM, "Simon Perreault" <[e-mail]> wrote:
> 
>>> - 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.

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.

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

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

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

+1 to more examples.

Peter

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