- From: Shane McCarron <shane@aptest.com>
- Date: Mon, 28 Feb 2011 08:25:19 -0600
- To: Ivan Herman <ivan@w3.org>
- CC: Manu Sporny <msporny@digitalbazaar.com>, Toby A Inkster <mail@tobyinkster.co.uk>, Harry Halpin <hhalpin@w3.org>, RDFa WG <public-rdfa-wg@w3.org>
- Message-ID: <4D6BB04F.6020305@aptest.com>
Well... we have no requirement that all host language default profiles are a superset of the RDFa+XML default profile. And indeed I can easily imagine a host language (ShameML) where I do not want terms defined in that profile. Or I do not want prefixes defined in that profile. Why would we have such a requirement? Second, even if we DID have such a requirement, it would certainly be more efficient to just require that the data be included in the profiles than to have each language processor read / process two profiles every time they parse a document. Wouldn't it? On 2/28/2011 12:02 AM, Ivan Herman wrote: > Shane, > > I may not understand what you say. But if I do, this is not a minor > issue. Indeed, the question is whether the core default profile is a > subset of the xhtml default profile or not. Put it another way, > whether all the prefixes and terms defined in the core profile should > be repeated in the xhtml profile, too. Manu's approach means that it > is unnecessary to do so, in your case it is. I happen to be on Manu's > side on this although, as we say, I would not lie down the road... > > Ivan > > ---- > Ivan Herman > Tel:+31 641044153 > http://www.ivan-herman.net > > > > On 28 Feb 2011, at 00:47, Shane McCarron <shane@aptest.com > <mailto:shane@aptest.com>> wrote: > >> Manu, >> >> A minor comment: >> >> On 2/20/2011 1:23 PM, Manu Sporny wrote: >>> ... >>> Profile Document Selection Algorithm >>> ------------------------------------ >>> >>> The RDFa WG discussed several algorithms for determining the correct >>> profile to use. In the end, the simplest and most reliable mechanism >>> seemed to be to do the following: >>> >>> 1. Always load the RDFa Core 1.1 default profile first. >>> 2. If an "application/xhtml+xml" or "text/html" MIMEType is detected, >>> load the HTML+RDFa 1.1 default profile. >>> >>> Step #1 will be placed into the RDFa Core 1.1 specification. Step #2 >>> will be placed into the (X)HTML Host Language specifications. >> >> I actually DISAGREE with this. I think it is more sensible to have >> the processor determine the media type, then act accordingly. In >> fact, we had already introduced text that supports that model [1]: >> >>> A conforming RDFa Processor /must/ examine the media type of a >>> document it is processing to determine the document's Host Language. >>> If the RDFa Processor is unable to determine the media type, or does >>> not support the media type, the RDFa Processor /must/ process the >>> document as if it were media type |application/xml|. See XML+RDFa >>> Document Conformance. >> >> I say this is a minor comment because I believe the effect on >> document processing is identical - it really just means that an >> implementation is not required to read / process TWO default profiles >> in what is likely to be the most common case. After all, I think we >> all expect that HTML4 / HTML5 documents are the most prevalent on the >> network. >> >> >> >> -- >> Shane P. McCarron Phone: +1 763 786-8160 x120 >> Managing Director Fax: +1 763 786-8180 >> ApTest Minnesota Inet:shane@aptest.com <mailto:shane@aptest.com> >> -- Shane P. McCarron Phone: +1 763 786-8160 x120 Managing Director Fax: +1 763 786-8180 ApTest Minnesota Inet: shane@aptest.com
Received on Monday, 28 February 2011 14:26:22 UTC