W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2012

Re: ISSUE-132 (Is @src allowed everywhere?): Is the @src attribute defined in RDFa Core allowed on any element? [3rd LC Comments - RDFa 1.1 Core]

From: Shane McCarron <shane@aptest.com>
Date: Mon, 20 Feb 2012 14:25:22 -0600
Message-ID: <4F42AC32.90105@aptest.com>
To: public-rdfa-wg@w3.org
Hmm...  I think I must respectfully disagree.  While you are correct 
that it would be up to the Host Language creator to define a language 
that is useful, I feel we have a responsibility to require that if you 
say a language incorporates RDFa Core that it actually does so.  You are 
right that a Host Language author could relegate one or more RDFa 
attributes to a disconnected backwater, but at least that would be a 
conscious decision on the part of the language author (e.g., I put @rev 
on an element named 'DontUseMe'), rather than an accident of content 
model definition  (e.g., I forgot to include @rev in a collection of 
attributes that was included everywhere).

You seem to think it would be okay to define a Host Language that didn't 
allow data typing. I think it is fine to create documents that don't USE 
data typing, but since ALL RDFa processors are required to support all 
of these attributes, it doesn't make any sense (to me) that we permit a 
Host Language to omit key aspects of RDFa.

RDFa without any attributes that define a predicate wouldn't be RDFa at 
all.  We shouldn't permit such a Host Language.  At least that's my opinion.

On 2/20/2012 2:10 PM, Jeni Tennison wrote:
> Shane,
> I think your language requires that *all* required RDFa attributes (ie everything but @href and @src) are permitted on at least one element within the Host Language.
> What I'm saying is that this requirement is contrary to what Host Language authors probably want from RDFa. Under this wording, a Host Language that purposefully didn't allow @datatype would be non-conformant. But a Host Language could claim conformance with RDFa by defining @datatype on an element that was optional in the content model with big warnings all over the spec for the Host Language saying "don't use this element!" Forcing a Host Language that wanted to use only parts of RDFa to jump through those hoops just makes RDFa annoying to incorporate.
> A Host Language that doesn't support some attributes means that people using it won't be able to express some RDF using RDFa, but that's the lookout of the Host Language. I think that the conformance section should state that to claim conformance all the RDFa attributes in a Host Language must, when processed to generate RDF, create the RDF defined by the RDFa Core processing, but not say anything about which of the attributes the Host Language needs to incorporate in its content models.
> Jeni
> On 20 Feb 2012, at 18:35, Shane McCarron wrote:
>> In my mind the language I proposed requires that an attribute be supported in a host language.  Therefore it would have to be supported on at least one element in order for the host language to be conforming.  Do you disagree?
>> On 2/20/2012 12:32 PM, Jeni Tennison wrote:
>>> Shane,
>>> On 20 Feb 2012, at 16:40, Shane McCarron wrote:
>>>> My suggestion would be that we do two things:
>>>> 1. Add text in the host language conformance clause that says "The required attributes defined in this specification must be included in the content model of the Host Language.  The elements on which these attributes can occur is at the discretion of the Host Language."
>>> If the elements on which the attributes can occur is at the discretion of the Host Language, then couldn't it decide not to enable any elements to have particular attributes? This might be used by a Host Language that only wanted to support RDFa Lite to limit its support to just the RDFa Lite attributes and not include eg datatype.
>>> So I don't think you can say that Host Languages MUST include all the required attributes in their content models. Obviously they will be better off (in the expressivity of RDFa that they can support) if they do, but I think the strongest you can go is a SHOULD.
>>> Jeni
>> -- 
>> Shane McCarron
>> Managing Director, Applied Testing and Technology, Inc.
>> +1 763 786 8160 x120

Shane McCarron
Managing Director, Applied Testing and Technology, Inc.
+1 763 786 8160 x120
Received on Monday, 20 February 2012 20:25:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:30 UTC