Re: the compatabiliity issue with metadata, I want to emphasize that
we have not yet settled on a proposal. So it may well be a little
premature to worry about, except as it may help us guide design.
However, my proposal for the model (a subset of RDF) presents the
following issues:
Here's an example of a current metadata file:
The removal of a single node -- the unncessary office:meta element --
would make this valid RDF.
So what would removing that element do to the compatability picture?
Moving on ...
Even with that change, it would not be valid against the more
contrained RDF syntax I have advocated [1], where I have said we
should not suppport using attributes for properties. The reason is
that if we are agnostic about attributes or elements (as RDF is) for
metadata properties, then we make things more complicated for xpath-
based tools if we allow either in arbitrary extension content.
Now, this may not matter. It may be easier to just recommend that
developers use elements instead of attributes, but not require it. In
that case, there's no problem.
The other thing is that we can restrict that flexibility only to
properties in the meta or office namespaces. I guess I favor that
myself.
Also, just to be clear, the current meta:user-defined element can go
away or be made simpler with the enhanced metadata support. Tim
Berners-Lee himself commented on this awhile back: