[Playlist] CDATA in URL sections?

[Matthias Friedrich]

On Monday, 2007-05-14, Sebastian Pipping wrote:
> Matthias Friedrich wrote:
[...]
> I found the collapse thing you talked about here [1].
> I compared that to the latest XML 1.0 spec [2] and
> it seems to me that the old "collapse" is the new "default"
> while "keep" is the new "preserve", right? Quite sad to see
> the old spec text is much clearer (to me) than the latest one.

> As I understood the former any whitespace (including tabs)
> is stripped or converted to a single space respectively.
> Do you have a link on this special role of tab characters?
> I'd like to read more about it before implementing this.
> Also do you have a link on whitespace handling for types
> not derived from string?

The "collapse" strategy I was actually talking about was from XML Schema
[1], but it also references XML 1.0 second edition. After re-reading
the paragraph, however, I realized that "replace" is executed before
"collapse", so in fact all tabs in anyURIs are rewritten to spaces.
Note that "replace" is only defined for a subset of the white space
characters (\t, \r, \n) though, not even for all in the ASCII set.

> Afaik Expat takes care of entity resolution so I wonder
> how the text "  " arrives at the application then.
> And I thought XML was easy...

If   isn't defined in XML by default, it's an error. I'm not sure
if the XML standard enforces a specific behavior in this case. On
first glance, it doesn't appear to.

[...]
> I'm with you for strictness. Since the XSPF v1 spec doesn't
> say anything about whitespace I think we should
>  * define the officially correct way to deal with whitespace
>  * add related testcases to the test suite
>  * add a note to "XSPF v1 Notes and Errata" # 1.5 Whitespace [3]

I think the XML data types we chose already define the correct
behavior, all that's left is to document it so people can implement the
normalization algorithm correctly in their applications.

> Regarding the definition what we in my eyes have for now is
>  * keep whitespace in all "real string" leaf elements
>  * ignore whitespace for non-leaf elements
>    (playlist, attribution, trackList, track)
>  * whitespace handling in extensions depends on the
>    specific extension

Correct.

> What is left is leaf nodes with dateTime, integer or URI
> content. Anything else?

dateTime, nonNegativeInteger, and anyURI are all atomic non-string
types, so the "collapse" strategy applies (which includes "replace", as
we learned).

Cheers,
	Matthias

[1] http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace