- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Thu, 24 May 2007 15:59:04 +0100
- To: RDFa <public-rdf-in-xhtml-tf@w3.org>
Hi José, You are more than welcome! Regards, Mark On 24/05/07, José Manuel Cantera Fonseca <jmcf@tid.es> wrote: > +1 also. > > By the way, after being convinced of not creating a new attribute for > classes :), I'm starting to participate (is a small participation :), I > know ) in discussions but I'm not a member of any of the groups involved > in this task force, although my company is a W3C member. Is that a problem? > > I guess that the answer is no. It's like other W3C groups that work in > public. The public can express opinions but the group has the last word. > > Thanks and best wishes > > Hausenblas, Michael escribió: > > Mark! > > > > +1 > > > > Would it be a partition by levels [1] then? > > > > Cheers, > > Michael > > > > [1] http://www.w3.org/TR/spec-variability/#subdivision-level > > > > ---------------------------------------------------------- > > Michael Hausenblas, MSc. > > Institute of Information Systems & Information Management > > JOANNEUM RESEARCH Forschungsgesellschaft mbH > > Steyrergasse 17, A-8010 Graz, AUSTRIA > > > > <office> > > phone: +43-316-876-1193 (fax:-1191) > > e-mail: michael.hausenblas@joanneum.at > > web: http://www.joanneum.at/iis/ <https://webmail.joanneum.at/exchweb/bin/redir.asp?URL=http://www.joanneum.at/iis/> > > > > <private> > > mobile: +43-660-7621761 > > web: http://www.sw-app.org/ <https://webmail.joanneum.at/exchweb/bin/redir.asp?URL=http://www.sw-app.org/> > > ---------------------------------------------------------- > > > > > > ________________________________ > > > > From: public-rdf-in-xhtml-tf-request@w3.org on behalf of Mark Birbeck > > Sent: Thu 2007-05-24 16:15 > > To: RDFa > > Subject: PROPOSAL: Split RDFa into two pieces--core attributes, plus language-specific 'interpretations' > > > > > > > > > > Hello all, > > > > I'd like to suggest that we split RDFa in two, as a way of addressing > > a variety of issues. This is slightly separate from the use of the > > @profile attribute, although could end up being related. > > > > > > MOTIVATION > > > > The main motivation for this is that we're finding out, in a piecemeal > > fashion that some features of RDFa are problematic in some browsers, > > or that some people think that one feature or another would cause > > confusion. It seems better to unroll any changes to host languages, > > and take RDFa 'back to its roots', a little, with a focus on > > attributes. However, instead of just making RDFa into a set of new > > attributes in the way that it used to be, we make use of everything we > > have learned about making metadata work in HTML, and create an > > 'interpretation' of > > > > > > PROPOSAL > > > > My picture of RDFa is that it can be seen as a series of 'layers'. The > > first layer would simply be the RDFa-specific properties, which could > > be applied to any mark-up. This gives us: > > > > @about > > @property > > @resource > > @datatype > > @content > > > > (Haven't got time to check if I've missed any...but you get the point. > > :) We also need @id/@xml:id, but we could say that it is provided by > > the host language.) > > > > Note that we could add elements to this list: > > > > link > > meta > > > > but I think they are only needed if we support reification, so we can > > put that to one side until that whole question is resolved. > > > > Anyway, RDFa-core (just a working name :)) would define these > > attributes, and describe how triples are generated from them. It would > > also describe how to get namespacing. (I mean this in the broadest > > sense of the term, as opposed to the XML namespace sense, and this > > will be described in a separate proposal.) The upshot of this 'level' > > is that we get something a bit like N3, using XML as the > > serialisation. > > > > > > Although these attributes can be applied to any language, there will > > often be semantic features available in the languages being augmented, > > so the second layer up is to describe how some particular language > > provides language-specific syntax. So, at this level, when applied to > > HTML 4.01 or XHTML 1.x, we might have @rel and @rev, @href, <link> and > > <meta>, and so on. We'd also say what happens to <img> and @src, and > > maybe even things like @hreflang. > > > > But whatever we define, my feeling is that at this level we should > > *not touch* the host language. So if HTML doesn't support '@href > > anywhere', then we don't add '@href anywhere' as a feature. In other > > words, all we are doing at this level is saying 'here is the RDF > > interpretation of existing mark-up', and of course adding the > > RDFa-core attributes. The process of creating the mappings could > > actually involve looking at all semantic features of a language and > > seeing what rules could be created form the language--so @title, for > > example, seems like it ought to generate an rdfs:label on a bnode. But > > the main point is that we should not _change_ the language, other than > > adding the RDFa-core attributes. > > > > The justification for this approach is that we then take no chances > > with what browsers can support; for example, we don't have any > > problems with <link> and <meta> being moved from body to head in some > > browsers, since we simply don't allow it. And we don't have to debate > > whether @href should be allowed anywhere, because again, we just don't > > allow it. It makes life a whole lot easier since instead of having to > > do laborious testing to work out whether browsers will support this > > feature or that, we just rely on the one feature that we know to be > > safe--the addition of the RDFa-core attributes. > > > > Now, there is nothing in this that stops new languages from being > > created that incorporate RDFa-core right into their heart, and then > > add more complex constructions, like <meta> anywhere, or @href > > anywhere. An example is obviously XHTML 2, although there could well > > be others. But the key change I'm suggesting is that it would be up to > > XHTML 2 to introduce ideas like '<meta> anywhere', '@href anywhere', > > and so on. Those ideas would not be in the core of RDFa, they would be > > part of the 'interpretation' layer, just like we have an > > interpretation of HTML that gives a meaning to @rel and @rev. > > > > Regards, > > > > Mark > > > > -- > > Mark Birbeck, formsPlayer > > > > mark.birbeck@x-port.net | +44 (0) 20 7689 9232 > > http://www.formsPlayer.com <http://www.formsplayer.com/> | http://internet-apps.blogspot.com <http://internet-apps.blogspot.com/> > > > > standards. innovation. > > > > > > > > > > > > > > > > -- Mark Birbeck, formsPlayer mark.birbeck@x-port.net | +44 (0) 20 7689 9232 http://www.formsPlayer.com | http://internet-apps.blogspot.com standards. innovation.
Received on Thursday, 24 May 2007 15:06:28 UTC