Alternate-prefix-declaration-mechanism
From RDFaWiki
Contents |
The Problem
With the release of XHTML1.1+RDFa, the only mechanism available for declaring prefixes is the xmlns mechanism.
Example:
<div xmlns:audio="http://purl.org/media/audio#" ...></div>
With the possible proliferation of RDFa into other tag-based languages, it is important to outline an alternate mechanism that does not assume the use of an XML-based language.
The Possibilities
There were a number of possibilities that were discussed over the course of four months in the RDF in XHTML Task Force. These alternate mechanisms can be viewed in the RDFa Test Harness by selecting "Design Test Suite" for the Test Suite and "Unreviewed" for the Unit Test Status. The alternate mechanisms included:
- A colon-based syntax
- A CSS-like syntax
- An equal-sign syntax
- A space-separated syntax
The discussions about these various syntaxes can be viewed online:
- January 08 2009
- January 22 2009
- February 19 2009
- March 05 2009
- March 19 2009
- April 02 2009
- April 16 2009
The Consensus
After careful deliberation, the group settled on a space-separated, equal-sign syntax. For example, the following are all valid uses of the @prefix attribute:
<div prefix="audio=http://purl.org/media/audio#" ...></div>
<div prefix="audio=http://purl.org/media/audio# video=http://purl.org/media/video#" ...></div>
<div prefix="audio= http://purl.org/media/audio# video = http://purl.org/media/video#" ...></div>
The following regular expression codifies the parsing rules for a single item in @prefix:
(.*)[\s\r\n]*=[\s\r\n]*(.*)[\s\r\n]+
In the regex match above, \1 would give you the prefix and \2 would give you the mapping. Executing the match repeatedly would give you all of the prefix-mappings.
Outstanding Issues
Changing the Default Prefix
Most of this discussion about changing the default prefix has happened offline over the past couple of months. During the telecons, we didn't discuss in detail or form a consensus on how one would override the default prefix.
The first option for changing the default prefix consists of markup that does not contain a prefix identifier:
prefix="=http://a.b.c/"
The second option consists of a keyword-based mechanism:
prefix="DEFAULT=http://a.b.c/"
We could discuss further if a number of people felt that we needed a mechanism to override the default prefix. It seems like we really should define such a mechanism.
Manu prefers a reserved word mechanism over the other method because:
- It would probably be easier for non-developers to understand.
- It would be harder to mistakenly override the default prefix.
- It would be easier for the parser writers to handle.
Error Conditions
There is currently not enough test coverage. More design tests need to be added to cover invalid markup such as:
prefix="aa="
or
prefix="aa= bb=http://a.b.c/"
Using xmlns and prefix in the Same Element
What happens if there is, on an element, both an xmlns and a prefix? For example, <bla xmlns:aa="http://www.w1.com/" prefix="aa=http://www.w2.com/"/>
There are currently mixed feelings on this. At first, we believed that xmlns and prefix would exist in the same language, but now there are concerns that this may confuse people (having two ways to do the same thing). This issue can be worked through, so let's assume that prefix and xmlns can be defined in the same document.
Manu believes that the current consensus is that you would process both lists, but one would take precedence over the other. So, for example, if @xmlns took precedence over @prefix, you would process @prefix first and then @xmlns. Any conflicting mappings would be overwritten when @xmlns is processed. The last defined value wins.
Shane agrees with Manu, but feels that there are not two "lists" from a processing model perspective. As a parser works through a document, it will learn about prefix mapping definitions from each element. As long as we define it this way, it does not matter which "list" takes precedence.
