Hi Helena,
Thanks again.
required elements
… so when I say "required", that is what I mean. Neither mastercomment1 nor commenta are required. I did know the other things but thought I was missing something.
<someElement/> (nothing) In FCP, we interpret the absence of an element to be "no element" which is _NOT_ the same as an empty string. (for users, however, you may be right that this experience is the same) Thanks and you're right and it's interesting I haven't thought about that difference. Would that mean if I provide for example a XML containing filmdata with all values left empty, the empty values will travel along with the next XML export from FCP. But I'll try that by myself.
… <someElement> </someElement> As you will have noticed, if you put any amount of white-space, at import time we've decided this is the same as an empty string since we don't know what else it may or may not be given that one may format XML as they will with whitespace. I do understand that. The problem I see (at least for me) is that if I use xmlLib2 to parse the XML and modify some values somewhere and then save the XML I'll see the above as: <someElement> </someElement> later. As some people like to use " " with their text generators to format text it's difficult to decide whether the " " is a user entry, a bad user entry or a FCP XML linefeed. So using ascii 10 instead of carriage return would solve the problem
why does FCP export mastercoment1 and not commenta when neither is touched? This is due to an implementation detail really so there isn't any logic to understand. So let's just say it is one of the quirks of FCP XML that sometimes we export a bunch of default values and that were we to have infinite time to fix bugs, we'd fix (if we got the bug). That's not a problem and as said above I thought I was missing something.
XML interpreted by first character. I wasn't sure about that
Thanks again Andreas |