See also: IRC log
<trackbot> Date: 10 March 2011
<scribe> scribe: Steven
Manu: I have made some updates
for different host languages
... I need to add back the RDF 1.0 work
... anyone can write and submit tests
Manu: Please add tests you come across when doing your implementations
Ivan: I've had problems accessing the site
Manu: You should have access
Ivan: I will try again
Manu: Ping me if you have problems
Ivan: We should ensure we use the DTDs etc for the 1.1 tests
<ShaneM> Feel free to use the XML Schema for validation too.
<manu> Is this the DOCTYPE you're talking about: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
Ivan: all the 1.0 tests are in
... do we need to repeat them in HTML5 and pure XML?
Manu: Yes. We have an HTML5 test
<manu> HTML5 testsuite suite uses: <!DOCTYPE html>
Ivan: It's nice to have SVG
... we now specify what it means to have a hostlanguage
... but we don't yet have an SVG hostlanguage
Manu: We use media type to identify the content types
<Zakim> ShaneM, you wanted to discuss media types
<ivan> 16:14 tmp> header http://rdfa.digitalbazaar.com/test-suite/test-cases/0001.xhtmlHTTP/1.1 200 OK
<ivan> Date: Thu, 10 Mar 2011 15:12:24 GMT
<ivan> Server: Apache/2.2.16 (Debian)
<ivan> Vary: Accept-Encoding
<ivan> Content-Type: text/html
Shane: Media type?
Steven: Same as XHTML1.1
Ivan: I've just tried, and it doesn't seem to be working right
Manu: I'll check
<ivan> alias header='curl --head '
Shane: Your client has to say it accepts the media type in order to get it
Ivan: I don't think curl sends an accept header
Manu: Oh, I don't change the content type. Bug. Will fix
Shane: If XHTML5 uses the same media type as XHTML 1 (and it does) then we don't know what versio
Steven: There is no difference in processing between XHTML5 and 1.1 surely
Shane: Not yet...
Ivan: The two are esssentially the same from an RDFa POV
... Therefore we don't need a separate XHTML5+RDFa testsuite then
Manu: I need to think about it
... we could have a separate selector for XHTML5 though
... the DOCTYPE of the result would change
... the RDFa rules don't take the DOCTYPE into account though
Shane: There was a thread in the last 5 days
Shane: He asked if it's OK to
look at the root element
... to determine the document type
... but you don't get a media type in a filesystem, so how do you know?
Ivan: Filename extensions are used to map to media types
<ShaneM> Gregg said in his mail: "I guess what concerns me is the requirements of a conforming processor. This depends on the interpretation of the third sentence (If the RDFa Processor is unable ...). I would hope/expect that a processor which uses unspecified heuristics to determine the document type (e.g., file extension, root element name, etc.) would not be inconsistent with this definition. If this leaves room for other forms of identification, perhaps the spec shoul
Shane: It is not required though
Ivan: It is the only way I can see it working
Shane: Gregg wants to know if you are nonconforming if you sniff
Manu: The decision to sniff
happens after all other means have failed.
... we don't need to specify that
... do we think there are many people with this issue?
... I don't think so
Shane: But, if you don't specify
it, you won't get interoperability
... I agree we don't need to lock it down
... "We don't specify behaviour in the environment of incorrect input"
Manu: I propose leaving it unspecified. Any objections?
Shane: Do we say that in the spec?
<ShaneM> I proposed: "If the media type is unavailable, a conforming RDFa Processor MAY look at the document's DOCTYPE to determine if its Formal Public Identifier matches that of a known Host Language."
<ShaneM> no reason to say this though
Shane: Or use a note
<ShaneM> NOTE: A conforming RDFa Processor MAY use additional mechanisms to attempt to determine the Host Language if the media type is unavailable. These mechanisms are unspecified.
<ShaneM> NOTE: A conforming RDFa Processor MAY use additional mechanisms (e.g., the DOCTYPE, a file extension, the root element) to attempt to determine the Host Language if the media type is unavailable. These mechanisms are unspecified.
Manu: I like that text
<manu> PROPOSAL: Add text to the RDFa Core document specifying a note that reads: NOTE: A conforming RDFa Processor MAY use additional mechanisms (e.g., the DOCTYPE, a file extension, the root element) to attempt to determine the Host Language if the media type is unavailable. These mechanisms are unspecified.
Ivan: It's fine
Ivan: I don't want to be obliged to do sniffing
<manu> RESOLVED: Add text to the RDFa Core document specifying a note that reads: NOTE: A conforming RDFa Processor MAY use additional mechanisms (e.g., the DOCTYPE, a file extension, the root element) to attempt to determine the Host Language if the media type is unavailable. These mechanisms are unspecified.
Manu: We are not going to review
test cases; we'll hear about it from users if any are
... OK with that?
Manu: I sent emails to all
reviews of LC1
... we have done our duty
Ivan: We don't need a reply; it would be good though
Manu: Nathan has to reply to Ian
... I haven't seen that reply yet
<manu> Toby has to respond to: http://www.w3.org/2010/02/rdfa/track/issues/74
Manu: We need to do these
... let's delay for a week to let them do that
Ivan: Maybe we should send replies
Manu: Delay a week?
Steven: But that risks LC3
Manu: The TAG says we should clarify that we cannot follow the specs to figure out what a fragid means when you use it in the way RDFa uses it
Steven: I hate that. Foaf:PrimaryTopicOf is much better
<ShaneM> I note that the TAG's job is to be pedantic.
Manu: The TAG says it is fine to use #me, but we need to say that you can't work out what it is
<manu> "In some of the examples below we have used URIs with fragment ids
<manu> that are local to the document containing the RDFa fragments shown
<manu> (e.g. 'about="#me"'). This idiom, which is also used in RDF/XML and
<manu> other RDF serializations, gives a simple way to 'mint' new URIs for
<manu> entities described by RDFa and therefore contributes considerably to
<manu> the expressive power of RDFa. However, the media type registrations
<manu> that govern the meaning of fragment identifiers (see section 3.5 of
Shane: It is nonnormative.
<manu> the URI specification RFC 3986, RFC 3023, and RFC 2854) have not yet
<manu> caught up with this practice. Uses of fragment identifiers that are
<manu> arbitrarily different from the meaning they are assigned by the
<manu> relevant media type registrations (eg. via @id) should be avoided. See
<manu> also AWWW 3.2.1."
Shane: The TAG should give us text if they think it's so important
<manu> I think that change is fine
Shane: Is this about using #id when there is no such id?
Manu: There is no spec that specifies the use of this use of fragids
Ivan: We're wasting time on this
Steven: It's our own fault for using it in our examples
Manu: OK with the text I pasted?
Shane: Up to the last sentence
Manu: I will strike it
<ShaneM> Strike the last sentence and move on.
Steven: Next week's call is an hour earlier for Europeans
Shane: New dated ED?
Manu: Nah. Just make the
... ping Gregg
Shane: Already done
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/test/testsuite/ Succeeded: s/SH/Sh/ Succeeded: s/FI/Fi/ Succeeded: s/U/u/ Succeeded: s/3r/r3/ Succeeded: s/TH/Th/ Succeeded: s/nant/ant/ Succeeded: s/iof/if/ Found Scribe: Steven Inferring ScribeNick: Steven Default Present: +44.123.456.aaaa, Ivan, Steven, +3539149aabb, Knud, Benjamin, ShaneM, manu Present: +44.123.456.aaaa Ivan Steven +3539149aabb Knud Benjamin ShaneM manu Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Mar/0050 Found Date: 10 Mar 2011 Guessing minutes URL: http://www.w3.org/2011/03/10-rdfa-minutes.html People with action items:[End of scribe.perl diagnostic output]