I didn’t mean to imply that. I meant to imply that as JAMS uses the data now, it is a list of XORs without context. The context is assumed by JAMS, if you loaded a list of XORs that weren’t songs … it’d get dumb about it and treat them as songs anyway.
I agree that an abstract data structure would be nice. Perhaps a UUID (or a subset of UUID to reduce bytes) to identify data types could be employed? Maybe build a registry so humans can look it up and understand what UUID is reserved for what data types? Potentially include a version as well, though honestly, UUIDs are large enough to have a new one for each new version.
For example, there might be a UUID for Type: Song, then another UUID for Type: Indexed List. Each item in the Indexed List is a tuple of (UUID, XOR). Now JAMS can load a playlist (which is an Indexed List) and check that each XOR corresponds to a song type that JAMS understands how to parse by checking its corresponding UUID. JAMS no longer would assume each XOR is a song, and should not-a-song be encountered, it could easily decide this isn’t a valid playlist for JAMS.
Copy/Paste and replace “XOR” with “MD url”, or have UUIDs which refer to XORs and others which refer to MD urls, then the second part of the tuples might contain XOR or MD url. Shrug. UUIDs are huge.
EDIT: I’m responding to comments in order, and I see these ideas are being hashed out in a number of ways after I already wrote this response here. This response still seems valid for quite a bit of different comments from @joshuaef @happybeing and @bochaco