How about app:scheme instead of app:categoryGroup ?
<app:categories fixed="yes">
<app:scheme
ref="http://myblog.example.net/categories";
fixed="yes" exclusive="no">
<atom:category term="foo" />
<atom:category term="bar" />
</app:scheme>
<app:scheme
ref="http://myblog.example.net/tags";
fixed="no" exclusive="no" />
<app:scheme
ref="http://myblog.example.net/type";
fixed="yes" exclusive="yes">
<atom:category term="contact" />
<atom:category term="event" />
<atom:category term="review" />
</app:scheme>
</app:categories>
wrt the exclusive attribute, some blogging systems only allow one
category per entry.
<app:categories fixed="yes">
<app:scheme
ref="http://myblog.example.net/categories";
fixed="yes" exclusive="yes">
<atom:category term="foo" />
<atom:category term="bar" />
</app:scheme>
</app:categories>
- James
Thomas Broyer wrote:
>
> 2006/6/8, Tim Bray <[EMAIL PROTECTED]>:
>>
>> At http://www.intertwingly.net/wiki/pie/PaceAPPCategories
>>
>> Based on PaceCategoryListing2. In an introspection document, you
>> either have an href= or you don't. If not, you contain atom:category
>> elements directly. If you do, it has to point to a Categories
>> document, whose root is <app:categories> with <atom:category>
>> children. The only thing that's not obvious is that
>> <app:categories>, when it's the root of a Categories doc, can have a
>> @scheme attribute to provide a default, if you want a couple of
>> hundred categories and not to provide the [EMAIL PROTECTED] for all of
>> them.
>>
>> This seems to be about the minimum I can think of that would give APP
>> category listing, without trying to stretch too far or solve the
>> whole problem.
>
> That's pretty good stuff, but:
> - appOutOfLineCategories shouldn't have a "fixed" attribute, as this
> one will be present in the "Categories Document"
> - app:collection should be able to contain more than one
> app:categories element (see below)
> - the "fixed" attribute should apply to the "scheme" if defined at
> the app:collections level, or to "any category in any (other) scheme"
> if not provided (see below)
>
> I envision app:categories as a "category scheme definition", along the
> line of the rank schemes in the ranking extension.
> It might be necessary to define a collection as:
> <app:collection ...>
> ...
> <app:categories scheme="http://myblog.example.net/categories";
> fixed="yes">
> <!-- These are my blog's categories, I can only add categories
> through the blog admin web interface (at least until APP comes with
> category management) -->
> <atom:category term="Family" />
> <atom:category term="Geekeries" />
> </app:categories>
> <app:categories scheme="http://del.icio.us/tags/"; fixed="no">
> <!-- these are tags already used in entries of the collection -->
> <atom:category term="Atom" />
> <atom:category term="protocol" />
> <atom:category term="photos" />
> </app:categories>
> </app:collection>
>
> My problem here is that I now can't say whether categories from other
> schemes are allowed or not…
> If the "http://myblog.example.net/categories"; scheme weren't "fixed",
> I could have used a single app:categories without a"scheme" attribute,
> which could have implied that any category from any scheme is allowed:
> <app:categories fixed="no">
> <atom:category term="Family"
> scheme="http://myblog.example.net/categories"; />
> <atom:category term="Geekeries"
> scheme="http://myblog.example.net/categories"; />
> <atom:category term="Atom" scheme="http://del.icio.us/tags/"; />
> <atom:category term="protocol" scheme="http://del.icio.us/tags/"; />
> <atom:category term="photos" scheme="http://del.icio.us/tags/"; />
> </app:categories>
>
> But how about, you can use categories from those schemes, which don't
> define a fixed set of terms, but no category from any other scheme?
> Would the following work?
> <app:collection ...>
> ...
> <app:categories scheme="http://myblog.example.net/categories";
> fixed="yes">
> <!-- These are my blog's categories, I can only add categories
> through the blog admin web interface (at least until APP comes with
> category management) -->
> <atom:category term="Family" />
> <atom:category term="Geekeries" />
> </app:categories>
> <app:categories scheme="http://del.icio.us/tags/"; fixed="no">
> <!-- these are tags already used in entries of the collection -->
> <atom:category term="Atom" />
> <atom:category term="protocol" />
> <atom:category term="photos" />
> </app:categories>
> <app:categories scheme="http://technorati.net/tags"; fixed="no">
> <!-- You can use categories from this scheme, but no one has
> been used already -->
> </app:categories>
> </app:collection>
> But now I've no way to tell that you could use any category from any
> other scheme (consider that if I start using a category from the
> "technorati" scheme, the definition becomes almost identical to the
> first one given above, wi the same problems).
>
> So how about a new categoryGroup element?
> <app:collection ...>
> ...
> <!-- the following fixed="yes" attribute tells clients that I don't
> allow categories from any scheme other than those that are explicitly
> allowed here; a value of "no" would tell them that they can use
> categories from any scheme -->
> <app:categories fixed="yes">
> <app:categoryGroup scheme="http://myblog.example.net/categories";
> fixed="yes">
> <!-- These are my blog's categories, I can only add
> categories through the blog admin web interface (at least until APP
> comes with category management) -->
> <atom:category term="Family" />
> <atom:category term="Geekeries" />
> </app:categoryGroup>
> <app:categoryGroup scheme="http://del.icio.us/tags/"; fixed="no">
> <!-- these are tags already used in entries of the collection -->
> <atom:category term="Atom" />
> <atom:category term="protocol" />
> <atom:category term="photos" />
> </app:categoryGroup>
> <app:categoryGroup scheme="http://technorati.net/tags"; fixed="no">
> <!-- You can use categories from this scheme, but no one has
> been used already -->
> </app:categoryGroup>
> </app:categories>
> </app:collection>
>
> Both app:categories and app:categoryGroup could be "out-of-line'd"
> using an "href" attribute.
>
>
> Constraints:
> * there MUST NOT be more than one app:categoryGroup with the same
> "scheme" value
> * if an app:categoryGroup has a "scheme" attribute, then its
> atom:category children MUST NOT have "scheme" attributes (as the value
> is "inherited" by scope context)
>
> [[ please do not skip the end of the message, there's some more
> thoughts and questions after the RNC schemas ]]
>
> RNC for app:categories in Introspection/Service Documents (might not
> be correct, given my poor knowledge of RelaxNG):
> appCollection =
> element app:collection {
> appCommonAttributes,
> attribute title { text },
> attribute href { text },
> ( appMemberType,
> & appCategories?
> & extensionElement* )
> }
>
> appInlineCategories =
> element app:categories {
> attribute fixed { 'yes' | 'no' }?,
> (appCategoryGroup*)
> }
>
> appOutOfLineCategories =
> element app:categories {
> attribute href { atomURI },
> (empty)
> }
>
> appCategories = appInlineCategories | appOutOfLineCategories
>
> appInlineCategoryGroup =
> element app:categoryGroup {
> attribute scheme { atomURI }?,
> attribute fixed { 'yes' | 'no' }?,
> (atomCategories*)
> }
>
> appOutOfLineCategoryGroup =
> element app:categoryGroup {
> attribute href { atomURI },
> (empty)
> }
>
> appCategoryGroup = appInlineCategoryGroup | appOutOfLineCategoryGroup
>
> RNC for Category Documents:
>
> namespace app = "http://purl.org/atom/app#";
> namespace atom = "http://www.w3.org/2005/Atom";
> namespace local = ""
>
> start = appInlineCategories | appInlineCategoryGroup
>
> [[ other definitions copied from the above "RNC for app:categories in
> Introspection/Service Documents" ]]
>
>
> With the above definitions, the only problem left is: what if an
> appOutOfLineCategoryGroup references a Category Document with an
> appInlineCategories root element?
> But I think it's basically the same problem as "what if an
> appCollection element references an Atom Entry Document?"
>
> I'm aware that it's not as simple as what you're proposing in this
> Pace, but it's not really difficult either and covers most (if not
> all) use cases.
>
> Finally, wrt to James' question about "exclusive" schemes, I think
> that if only one value is acceptable, then it's not really a
> "category", but something else that people tried to implement without
> inventing anything and (badly) reused an existing syntax construct…
> Wrt to category labels, I'd say that servers shouln't reject entries
> only because of a category using a different label, they should either
> keep the sent label, or ignore it and use a "default" one (as
> eventually exposed in the app:categories/app:categoryGroup children)
>
