vcard DTD

[Mark D. Anderson]

>> nor what they do with "<" or "&" in a vCard value or parameter.
>
>So what's the issue here?  Dave Winer mentioned a similar issue
>that forced him to encode some text in "base64" ...
>
>Are XML-emitting tools just being incorrect?  "<" in text should
>always be encoded as "&lt;" (it'll be un-encoded during parsing),
>and "&" as "&amp;" (ditto).

I don't think there are any deep or hard issues here, and I
have no idea what tools do; my observation was about the spec --
and a spec that talks about exchange between two syntaxes (syntaces?)
should be very explicit about encoding issues. This means consideration
of the (different) sets of special characters in the two syntaxes,
and the (different) mechanisms each has for specifying 
binary encoding, character escaping, and so on.

For example, there are similar issues in reverse, if an xml-encoded
vCard had a postal address element cdata with a semi-colon in it.
These are easy to surmount, but the issues should be explicitly identified.

BTW, while substitution with &lt is certainly the simplest
approach, I could imagine scenarios where a structured xml value
for a vCard NOTE value might be a nice thing. Admittedly, I'm stretching.

-mda

p.s.: now that i think about it, transcoding a vCard also introduces
the question of what should be done with vCard PRODID. Is anyone from
vCard/iCalendar on this list?


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)