This issue is being opened to deal with the conflict between e-content and the draft u-photo property as well as the u-video/u-audio properties as all three have this similar issue. A proposed solution must be derived prior to any of the three reaching stable status.

Summary of Issue: u-audio, u-video, and u-photo all reflect that one of more audio, video, or photo urls is the primary content of the entry. Separately, it is a not uncommon scenario that img, video, or audio tags are present in the e-content, either marked up with microformats or not. This creates a possible duplication issue for those consuming parser output.

Some of this issue was previously discussed in aaronpk/XRay#52, specifically how parsers will consider an img tag inside e-content as an implied photo. This is a problem for resolving this. Currently, the parsing specification does not do the same for implied video or implied audio properties.

To address publishing examples of how people use u-photo vs. e-content:

• u-photo(s) inside e-content e.g. @kartikprabhu @tantek
• u-photo(s) as a sibling to e-content - with separate img tags for each
• u-photo(s) as a sibling to e-content - only img tag for u-photo, no img tag in e-content e.g. @dshanske
• u-photo(s) mixing with an article (non-empty p-name) <-- we consider this an erroneous use of u-photo as this is a pattern often used by people who believe u-photo is to be placed on all img tags. (In this case, the question was raised of whether or not this would reflect a photo with a name, e.g. like a flickr photo?)

The questions raised by this is whether these versions are meant to be interpreted differently and how to interpret them, what should be the recommended way, if any, to address this.