W3C home > Mailing lists > Public > www-tag@w3.org > December 2011

Re: ACTION-509

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Fri, 02 Dec 2011 18:57:48 +0000
To: Jeni Tennison <jeni@jenitennison.com>
Cc: "www-tag@w3.org List" <www-tag@w3.org>, Jonathan Rees <jar@creativecommons.org>, Noah Mendelsohn <nrm@arcanedomain.com>
Message-ID: <f5b7h2ekdhv.fsf@calexico.inf.ed.ac.uk>
OK, now I guess I see the problem that stalled things in October.

My view is that for FYN, _all_ the spec. of a markup language which
explicitly allows RDFa markup can (or should) do is reference RDFa
Core.  Requiring each such markup language spec. to reference RDF
Concepts is neither necessary nor even appropriate.  So I'm still
happy with my proposed wording (i.e., yours w/o the last sentence),
along with the agreed strong underlining of the necessity for the
HTML5 spec. itself to acknowledge RDFa (because that _is_ required for
FYN to work):

Another way to put this is that your sentence is tautological:  The
spec. for a language which incorporates RDFa does so by referencing
RDFa Core, which contains the key sentence about RDF Concepts, and so
satisfies your requirement.  And in my view it's important that the
dependence on RDF Concepts be kept local to RDFa Core, and _not_
spread across the universe of languages which explicitly include RDFa.

There's another reason too -- for me, it _must_ be sufficient for RDFa
Core to reference RDF Concepts, because for languages such as XSLT and
XML Schema which allow foreign-namespace attributes, the RDFa
namespace (if the RDFa WG do the right thing and specify that as the
namespace to use in such cases) must be sufficient, for FYN to work,
via their namespace doc't to the RDFa Core spec.

       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
Received on Friday, 2 December 2011 18:58:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:41 UTC