 |
 |
"Weibel,Stu" wrote: > I'm sympathetic to the argument that unapproved qualifiers should > not be given defacto endorsement in the the HTML draft, but at the > same time, we all know that virtually all DC implementations use > some form of qualifiers, and it is important that John's document > give the best guidance that we can to support this syntactically, > even if we don't agree on the qualifier semantics. I agree that there is an identified need for users/implementers of DC to have at their disposal means by which they can express "more" than the 15 unqualified properties defined in DC 1.0. I do not agree that having a syntax that allows implementers to introduce qualifiers in a completely arbitrary fashion (i.e. without any rules or restrictions) is a good way to satisfy this need. It would have been much better if there (at least) had existed some sort of reference model for qualified Dublin Core _before_ we started to introduce syntactical support for them . Starting out by defining syntax without semantics is not my idea of sensible design. But enough whining. If we are to provide implementers with a syntax to create qualified Dublin Core, we should at least provide some guidelines that makes it simple to distinguish between "standard" and "non-standard" qualifiers. One mechanism, which has been used in electronic mail for some time with considerable success, is to reserve the initial string "X-" and require all non-standard header fields to start with this string. I propose that we require implementers to follow a similar convention. I therefore propose that the following text is inserted into Kunze's document: Implementers wishing to convey non-standard properties, subelements or schemes SHOULD use names beginning with "X-". No standard property, subelement or scheme will ever be of this form. Reading agents SHOULD ignore properties containing "X-" elements, or at least treat them with great care. For example, if I want to qualify the standard DC element "DC.Type" with a non-standard qualifier that redefines its semantics to be a container for the programming language of the resource, I must use the following form for the qualified property: DC.Type.X-Proglanguage Using just 'DC.Type.Proglanguage' would constitute an error. Likewise, if I want to use values from the ACM Computing Classification System for DC.Subject, I must use the following: scheme="X-CCS" Using just 'scheme="CCS"' would constitute an error. As there exist no "standard" qualifiers or controlled list of terms for scheme etc. at the momemt (?) this means that all exaples in Kunze's draft showing use of qualifiers and schemes should show them with a "X-" prefix. -- - gisle hannemyr ( [log in to unmask] - http://home.sol.no/home/gisle/ ) ------------------------------------------------------------------------ "Use the Source, Luke. Use the Source." -- apologies to Obi-Wan Kenobi ------------------------------------------------------------------------ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%