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) -- Thomas Broyer
