RE: Categories and fixed="yes"

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Eric Scheid wrote:
> On 29/11/07 12:38 PM, "Joe Cheng" <Joe.Cheng@xxxxxxxxxxxxx> wrote:
> 
> > Well, you're worse off if there are nodes that have the 
> same term but 
> > have Different parents (which WordPress allows).
> 
> Could you point me to an example of this so I can see what you mean?
> 
> You're still no worse off than if your processor can't safely 
> guess hierarchy from the @term values. For example:
> 
>     <category term="001011" label="Cuisine" />
>     <category term="001012" label="Language" />
>     <category term="001013" label="French" x:BT="Cuisine" />
>     <category term="001014" label="French" x:BT="Language" />
>     <category term="001015" label="German" x:BT="language" />

I think Joe was talking about the way that WordPress does it now, where
it uses the label as the term instead of the unique ID. If WordPress
were to change to use the mapping you suggest, then at we would all be
able to two different "French" categories, which would be an improvement
over the current situation. We would be able to identify the old
WordPress mapping by the missing label attribute for
backwards-compatibility.

But, a feed reader wouldn't be able to understand the hierarchy, because
the entry would be have just:
	<category term="001014" label="French"/>
	<category term="001015" label="German"/>   
Even including the x:BT attribute would not help, if there are no
entries in the feed that were labeled "Cuisine" or "Language". And, if
the application has access to the hierarchy information, then the x:BT
attribute would be redundant.

I think a reasonable combination of all the ideas would work. Entry and
feed documents would have category elements looking like this (plus the
optional scheme attribute):

    <category term="001013" label="Cuisine - French"/>
    <category term="001014" label="Language - French"/>
    <category term="001015" label="Language - German"/>

And, the category documents would look like this (plus the optional
scheme attribute):

	<category term="001011" label="Cuisine" />
	<category term="001012" label="Language" />
	<category term="001013" label="Cuisine - French"
                x:BT="001011" x:short-label='French'/>
	<category term="001012" label="Language - French"
                x:BT="Language" x:short-label='French'/>
	<category term="001012" label="Language - German"
                x:BT="Language" x:short-label='German'/>

Note that x:BT should link by the term instead of by the label, because
the terms are unique but the labels aren't.

Many applications that don't understand the hierarchy will still work
reasonably well (better than currently), and applications that do
understand the hierarchy will work in a more-or-less ideal manner.

> Expressing the broader-term relationship concept as an 
> attribute of course assumes only one such per term. If you 
> need to express a polyhierarchy you could use child elements 
> instead, like this:
>
>     <category term="001013" label="French">
>         <x:broader term="001011">Cuisine</x:broader>
>         <x:broader term="001012">Language</x:broader>
>     </category>

Sure, but when this foreign markup (the x:* attrbutes and/or elements)
is in the service/category documents, clients are likely to
(unnecessarily) copy the foreign markup into the entries that they
POST/PUT to the collection.

- Brian