public page 5 - Dave's Blog

Tag Metadata in Feeds

2008 Aug 25, 10:13

As noted previously, my page consists of the aggregation of my various feeds and in working on that code recently it was again brought to my attention that everyone has different ways of representing tag metadata in feeds. I made up a list of how my various feed sources represent tags and list that data here so that it might help others in the future.

Tag markup from various sources

Source	Feed Type	Tag Markup Scheme	One Tag Per Element	Tag Scheme URI	Human / Machine Names	Example Markup
LiveJournal	Atom	atom:category	yes	no	no	, (source)
LiveJournal	RSS 2.0	rss2:category	yes	no	no	technical (soure)
WordPress	RSS 2.0	rss2:category	yes	no	no	, (source)
Delicious	RSS 1.0	dc:subject	no	no	no	photosynth photos 3d tool (source)
Delicious	RSS 2.0	rss2:category	yes	yes	no	domain="http://delicious.com/SequelGuy/"> hulu (source)
Flickr	Atom	atom:category	yes	yes	no	term="seattle" scheme="http://www.flickr.com/photos/tags/" /> (source)
Flickr	RSS 2.0	media:category	no	yes	no	scheme="urn:flickr:tags"> seattle washington baseball mariners (source)
YouTube	RSS 2.0	media:category	no	no	no	label="Tags"> bunny rabbit yawn cadbury (source)
LibraryThing	RSS 2.0	No explicit tag metadata.	no	no	no	n/a, (source)

Tag markup scheme

Tag Markup Scheme	Notes	Example
Atom Category atom:category xmlns:atom="http://www.w3.org/2005/Atom"	category/@term Required category name. category/@scheme Optional IRI id'ing the categorization scheme. category/@label Optional human readable category name.	term="catName" scheme="tag:deletethis.net,2008:tagscheme" label="category name in human readable format"/>
RSS 2.0 category rss2:category empty namespace	category/@domain Optional string id'ing the categorization scheme. category/text() Required category name. The value of the element is a forward-slash-separated string that identifies a hierarchic location in the indicated taxonomy. Processors may establish conventions for the interpretation of categories.	domain="tag:deletethis.net,2008:tagscheme"> MSFT
Yahoo Media RSS Module category media:category xmlns:media="http://search.yahoo.com/mrss/"	category/text() Required category name. category/@domain Optional string id'ing the categorization scheme.	scheme="http://dmoz.org" label="Ace Ventura - Pet Detective"> Arts/Movies/Titles/A/Ace_Ventura_Series/Ace_Ventura_-_Pet_Detective
Dublin Core subject dc:subject xmlns:dc="http://purl.org/dc/elements/1.1/"	subject/text() Required category name. Typically, the subject will be represented using keywords, key phrases, or classification codes. Recommended best practice is to use a controlled vocabulary.	humor

Update 2009-9-14: Added WordPress to the Tag Markup table and namespaces to the Tag Markup Scheme table.

feed media delicious technical atom youtube yahoo rss tag

Wp64 Issues

2007 Aug 6, 3:43Miladin told me about the Visual Studio compiler's promising option Wp64 that finds 64bit portability issues when compiling in 32bit. If, for instance, you cast from a (long*) to a (long) you get a W4 warning. However, the #defines are still set for 32bit builds. This means that other parts of the code can make assumptions based on the #defines that are valid on 32bit but generate 64bit errors or warnings.

For instance, in winuser.h the public published Windows header file there's the following:

...
#ifdef _WIN64
...
WINUSERAPI
LONG_PTR
WINAPI
SetWindowLongPtrA(
    __in HWND hWnd,
    __in int nIndex,
    __in LONG_PTR dwNewLong);
...
#else  /* _WIN64 */
...
#define SetWindowLongPtrA   SetWindowLongA
...
#endif /* _WIN64 */
...

In 64bit everything's normal but in 32bit SetWindowLongPtrA is #defined to SetWindowLongA which takes a LONG rather than a LONG_PTR. So take the following code snippet:

...
LONG_PTR inputValue = 0;
LONG_PTR error = SetWindowLongPtrA(hWnd, nIndex, inputValue);
...

This looks fine but generates warnings with the Wp64 flag.

In 64 bit, p is cast to (LONG_PTR) and that's great because we're actually calling SetWindowLongPtrA which takes a LONG_PTR. In 32 bit, p is cast to (LONG_PTR) which is then implicitly cast to (LONG) because we're actually calling SetWindowLongA. LONG and LONG_PTR are the same size in 32bit which is fine but if you turn on the Wp64 flag there's a W4 warning because of the implicit cast from a larger size to a smaller size if you were to compile for 64bit. So even though doing a 32bit or 64bit compile would have worked just fine, if you turn on the Wp64 flag for 32bit you'd get an error here.

It looks like I'm the most recent in a list of people to notice this issue. Well I investigated this so... I'm blogging about it too!wp64 technical 64bit compiler c++ visual-studio setwindowlongptra