See also: IRC log, previous 2006-04-18
Steven: most HTML authors think the words "tag" and "element" mean the same thing
ACTION: [DONE] Ben draft mail to Guus and David regarding continuation of HTML TF work [recorded in http://www.w3.org/2006/04/18-htmltf-minutes.html#action01]
ACTION: Ben start separate mail threads on remaining discussion topics [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action04] [CONTINUES]
ACTION: Ben to draft full response to Bjoern's 2004 email [recorded in http://www.w3.org/2006/01/24-swbp-minutes.html#action03] [CONTINUES]
ACTION: once Steven sends editors' draft of XHTML2, all TF members take a look and comment on showstopper issues only [recorded in http://www.w3.org/2006/02/06-htmltf-minutes.html#action01] [CONTINUES]
Mark: I'm going through and collecting all the little decisions to update the separate RDF/A spec doc
-> 24 April Primer editors' draft
Ben: This draft needs further checking to be sure we've addressed all comments. The new section 2 side-steps the issue of HTML frag ids (also) naming physical objects
Steven: I agree that #frag ids in HTML docs should be able to refer to non-information-resources
Ben: some people hold the position that #frag in an HTML document cannot name physical objects. Pat Hayes says such URIs can be either documents or physical objects; it doesn't matter
Mark: it seems odd to me to treat the HTML resource space in this special way
Ben: DanC has said that if an HTML document does not contain id="car" then it's ok to refer to a physical car with "#car"
Mark: then what happens later if the id is added to the document?
Ralph: my understanding of the TAG's position is that the server distinguishes between information resource and non-information resource by returning 200 or 303. So doc#car refers to an information resource if the server returns 200 and if doc#car is meant to refer to a physical object, the server should return 303. I'm trying to understand if this is deployable
Ben: I hope to ask the SWBPD WG for reviewers to read this new draft starting Wednesday with a target to get WG to approve publishing at its 8 May telecon. In the new section 2 I use role attribute to signal rdf:type
Steven: I saw that and liked it
RESOLVED to ask the SWBPD WG to review this editor's draft and submit for publication
Steven: what about section 5?
Ben: I was planning to leave it as is for this version. I would like to re-engage the Dublin Core community and add a Dublin Core section in a future version
Steven: I think it would be nice to have summaries of some of the main vocabularies that people are likely to use
Mark: Google Calendar has a nice data structuring convention that can be read by both RSS and ATOM so iCal folk can use this immediately
<MarkB_> Google Data APIs Protocol
<MarkB_> Common Elements: "Kinds"
<MarkB_> e.g., gd:email
Ben: it would be great to have examples based on Google's gdata vocabulary
Mark: since we agreed last week that rel can have multiple values, it's easy to markup in multiple vocabularies
Steven: about= on head rang bells
Mark: about= on head was a recent idea; we've not yet settled this; about="" on head isn't resolved
<benadida> issue 17: head edge case: default about
Ben: I had a proposal to specify a default about="" on the HTML root element. This would make meta and link in the head work as before. It might be good to add default about="" to body as well, though this isn't needed for backward compatibility
Mark: I think it will make the processing rules easier if we specify that body has a default about=""; rather than specifying that the default subject is the current document, we specify that the processor looks up the tree to find the first about attribute. So some other language, e.g. SVG, could change the default subject by adding their own 'about' if they wish
Steven: this does solve the problem but I'd hoped we would not have to make special cases. If we can find a better solution, I might prefer it
Ben: so introducing the special case on body may be too much
Steven: the proposal to add default about="" to body is new and I don't see the justification
Ben: meta and link in the head have previously referred to the whole document so adding about="" to the head is an obvious solution
Mark: let's separate the head and body issues. I'm proposing to make things consistent. How do you generally declare the rule that the default subject is the current document? We could eliminate a rule elsewhere by using the same technique on body as on head
Ben: we could add the about="" default to _both_ the root HTML element and the HEAD element; this makes frames also refer to the current page and avoids special-case for body
Mark: this would work except for a problem with other rules such as html:base; if head contains html:base then the subject should be the base URI
Ben: but html:base has no children
<MarkB_> <html>
<MarkB_> <head>
<MarkB_> <meta ... />
<MarkB_> <base ... />
<MarkB_> </head>
<MarkB_> .
<MarkB_> .
<MarkB_> .
<MarkB_> </html>
Ben: it's OK if HTML defines other ways to establish the current URI
Mark: an RDF/A processor has to find html:base to know the document's URI
Ben: I'm confused why the triples refer to the html:base value. There is still a document at the (non-base) URI so we have to think carefully about the semantics of html:base. Why should the subject of the triples change from the URI at which the document was fetched?
Mark: html:base changes the base for relative URIs cited within the document. about="" is by definition relative to the "current URI" of the document and html:base can change the current URI. We need a rule to say what happens in the absence of an about attribute
Ben: so to get compatibility for meta and link is to add an explicit about="" to head
Mark: the reason for this is that meta and link refer explicitly to their parent
Steven: if we add implicit about="" to the head for backward compatibility then whatever we do to the HTML root element we should say does not change the HEAD element
Mark: so if you want to make statements about whatever you named in the root, you put those statements in the body. Think of the example posted to the list a few weeks ago from someone who wanted to use the RDF/A syntax in an OWL document to avoid having to repeat attributes
Ben: so we're sticking with the rule that the processor searches up the tree to find about=; the only change we make is to add explicit about="" on head, which can be overridden by user
Mark: I will put this in my XHTML1 schema
RESOLVED: we're sticking with the rule that the processor searches up the tree to find about= and add explicit about="" to head
Ben: who should have the action to think about the HTML namespace URI issue?
Steven: propose SWBPD takes this issue but doesn't this go away with CURIEs?
Ben: we want CURIEs to be backwards-compatible with QNames
[adjourned]