On Sep 22, 2009, at 10:30 PM, Manu Sporny wrote:
I think the frustration level in this thread is rising to the point
that
we're not going to be able to make good progress if it continues much
longer,
Actually, it seems to me that the thread was doing a good job of
getting down to the core issues, and in expressing that in terms of
concrete problems.
so let me propose a set of solutions and then have Jonas, Henri
and Maciej weigh in on whether or not they think that the set of
solutions will address their issues:
Your proposed actions below sound good to me. I will note also that,
despite some claims to the contrary, the XHTML+RDFa processing model
is already defined in terms of traversing a DOM, while not requiring
implementations to actually have a DOM, as long as they behave in an
equivalent way. So I think what you describe below can be done without
a lot of additional spec complexity. You don't have to define a whole
new form of the processing model for non-DOM implementations, you can
just fill in some of the details in the model that XHTML+RDFa already
uses.
* Normatively define how a DOM-based implementation should work for
those parts that people feel are not clear. This would only clarify
what DOM-based implementations should do and would not require
implementations to use a DOM to be viewed as a conformant RDFa
processor.
* Normatively define how a DOM-based implementation should create
prefix mappings. This would only clarify what DOM-based
implementations should do and would not require implementations to
use a DOM to be viewed as a conformant RDFa processor.
* Add test cases for every single one of Philip Taylors xmlns: tests
as well as any other tests that he has in his test suite where
implementations differ in the triples that they produce. Philip,
can you help me produce these tests?
* If any of Philip Taylor's tests cannot be traced back to language in
the HTML+RDFa, XHTML+RDFa spec, or other normative spec in an
unambiguous way, then we must add language /somewhere/ to clarify
why a test case operates in a certain manner.
To execute on these goals, we can do the following:
1. Discuss what language should be created or altered in an upcoming
RDFa Task Force telecon.
2. Edit the HTML+RDFa specification to add the normative language for
DOM-based implementations.
3. Get all of Philip's tests migrated into the RDFa Test Suite.
4. Map each of Philip's tests to normative language in a
specification,
and if there is no normative language, create normative language.
Jonas, Henri, Maciej - does this seem like a good way forward? Is
there
any other issue that was raised that should have a bullet item? If so,
please summarize the issue in 1-2 sentences - don't elaborate on it if
it was already covered in this discussion. I'm speaking with Henri
tomorrow morning at 9am, and will try to get some further
understanding
of his non-DOM (XOM) issues.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Pirate Bay and Building an Equitable Culture
http://blog.digitalbazaar.com/2009/08/30/equitable-culture/
