See also: IRC log
Steven: XHTML2 Editor's draft announcement still pending
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]
ACTION: [PENDING] Jeremy followup on edge case [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action03]
ACTION: [PENDING] Jeremy followup with Mark on the question of multiple triples from nested meta and add to issues list [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action01]
ACTION: [PENDING] Jeremy propose wording on reification [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action02]
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]
Ben: awaiting discussion of RDF/A Containers
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 write out a proposal for how OL and UL turn into rdf:Seq and rdf:Bag [recorded in http://www.w3.org/2006/02/06-htmltf-minutes.html#action08] [DONE]
ACTION: Ben update the editor's draft to add to section 2 [recorded in http://www.w3.org/2006/02/06-htmltf-minutes.html#action09] [DONE]
<danbri> [rdf:Bag, eek.... i'm out of touch...]
<scribe> -- done
ACTION: Ralph add a sentence to 2.2.3 pointing to a citation for the triples syntax [recorded in http://www.w3.org/2006/02/13-htmltf-minutes.html#action09]
Mark, Ben: the citation to the triples syntax does not need to hold up the first working draft
Steven: Primer is being served with wrong character encoding
Ben: saw that, but might be confusing to debug until the .html variant exists
Steven: just change the META element in the
doc
... the document really is ISO-Latin-1
<jeremy> check documentation for xsl:output
<jeremy> I think it has a flag for encoding
Jeremy: the HTML output method of XSLT defaults to Latin-1, I believe, so look for a flag to specify UTF-8 as the output encoding
ACTION: Ben resolve the document encoding issue [recorded in http://www.w3.org/2006/02/13-htmltf-minutes.html#action10]
<jeremy> <xsl:output
method = "xml" | "html" | "text" | qname-but-not-ncname
version = nmtoken
encoding = string
omit-xml-declaration = "yes" | "no"
standalone = "yes" | "no"
doctype-public = string
doctype-system = string
cdata-section-elements = qnames
indent = "yes" | "no"
media-type = string />
<jeremy> try encoding="utf-8"
Jeremy: the first attempt at implementing things other than verification. Ralph reported some bugs, not too surprising
Ralph: I have neglected to provide test cases to Jeremy for the bugs I believe I found
Ben: our issues page lists several issues that I believe we've resolved. Let's document those we have resolved explicitly
Ben: this issue we resolved by CURIE
Steven: yes, we've resolved to use option B
Ralph: there is not Team consensus on the CURIE proposal so I must abstain
Steven: I told the HTML WG long ago that the TF chose option B
RESOLVED: issue 1 option B chosen
DanBri: abstain as I've been out of the loop for a while
Ben: I believe we've tentatively resolved this again using CURIEs
<benadida> _:foo
<benadida> [_:foo]
<benadida> _:foo is the CURIE
<benadida> [_:foo] is the CURIE/URI
<danbri> I don't see 'blank' or 'anonymous' in http://www.w3.org/2001/sw/BestPractices/HTML/2005-10-21-curie
<danbri> (as steven says)
Ben: '_' is the mechanism that specifies this is a bnode. This detail may be missing from the current documentation. We've chosen not to raise the topic of bnodes in the Primer
<jeremy> (note: "_" is a valid xmlns ... )
Ralph: the intent is that there is a local identifier in the document that is not exported
Jeremy: DAWG has been clear in SPARQL that applications _may_ reveal their bnode identifiers
DanBri: bnode identifiers must not be confused with URIs
Mark: so we have to be careful to specify that the expansion is to either a URI or a bnode
<danbri> [is there an escaping mechanism in CURIE? if i wanted a CURIE that began with _ for some non-bnode purpose?]
<jeremy> NCName ::= (Letter | '_') (NCNameChar)*
Jeremy: choosing a different leading character adds weight to our conclusion [on the desirability of a new production not reusing QName] as QNames in N3 are misleading; here's another case where N3 differs from QName spec
Ralph: '#' might convey the idea that these are local identifiers
<benadida> about="#foo" vs. about="[#:foo]"
Mark: perhaps just [:foo]
Jeremy: N3 uses :foo for the default namespace
Mark: if you don't know a mapping for '_' then we could still specify that URI names and bnode identifiers are disjoint
Jeremy: we don't actually need to support people who use "_" for a namespace prefix
Mark: but this creates an issue for the processor implementation
Jeremy: could say that any prefix that is undefined maps to itself so http: maps to itself when you're expecting a CURIe
Ralph: I like #foo and #:foo
<jeremy> !*$%^
<jeremy> =@~
Mark: another alternative: we have the idea of a CURIE that is understood as a CURIE in context without '[]' but Steven also suggested an alternative leading character
<jeremy> _: is bnode, @pre:foo is qnamelike, as is @_:foo
Ben: it may be that bnodes will only appear in the case where '[]' is required so '_' inside '[]' could be defined as different from '_' in QName
Jeremy: leading '@' could behave in the way that '[]' have been
Mark: in some situations we want to write both a:b and _:b so we have context in which the type is implicit but we also have [a:b] and [_:b] to make the type explicit
Ben: as bnodes appear only in subject and object positions, the current syntax forces bnode identifiers to be in '[]'
Mark: but I'm trying to find a way not not have to change the meaning of '_'
Ben: clearly issue 5 is still open; I will summarize the options now on the table
Steven: I believe issues 4 and 7 [syntactic sugar for role (4) and class (7) attributes] are essentially the same and can be combined under one discussion
ACTION: Ben summarize the syntax options for issue 5. (Local) blank node identifiers [recorded in http://www.w3.org/2006/02/13-htmltf-minutes.html#action11]
Ben: we've not had any debate about whether 'about' and 'href' can both contain CURIEs. If we restrict these to CURIE only, not CURIE/URI, we get backwards compatibility
<danbri> re html link types vocab, that's at /2005/05/hrel/ (can it go on the issues list?)
Mark: I think it would be good to require CURIE syntax as the default namespace might not be the HTML namespace as we've resolved issue 11. There is important consistency in having attributes all behave in the same way; '[]' generally required, URI permitted so an author does not have to go to the effort of defining a namespace just to use a single URI. E.g. things like SKOS where the document contains a taxonomy; an author would get fed-up having to define lots of namespaces
<danbri> [I helped SKOS but Alistair Miles is Dr SKOS :]
Mark: but I don't see a problem with the processor having to explicitly recognize these special terms; it's a known, finite list
<danbri> (I'm wary of too many builtins)
Steven: disagree; one of our aims is to make this all look as much as possible like traditional HTM. [It would be bad] to have rel='next' mean something different than href='next'. Even though we think of 'rel' value as being a URI, the World doesn't see it that way
<benadida> +1 to Steven
Steven: I think that rel is something different for an HTML author, therefore a different syntax is not a problem
Jeremy: it's awkward to create namespace prefixes but not hopeless
<danbri> (if rel='next' and href='next' mean different things, that'll be hard to teach...)
Jeremy: in the case of an embedded taxonomy it's not a huge pain to delcare one more namespace
<Zakim> benadida, you wanted to mention the [] syntax
Jeremy: the case of only needing to use a prefix once is the bigger nuisance
Ben: I favor Steven's approach. The '[]' syntax is the weakest proposal from this Task Force; it's the proposal that has raised the most concern from outside so the more we force it to be used the more objection we can expect. We can special-case all the strings in the current HTML spec
Steven: special-casing causes extensibility to go out the window
<danbri> (I'm reminded of the xpointer registry...)
Steven: if we want to add a new string in the next version we have to special-case it too
Mark: not really special casing, just saying the URI base is different. But we do lose consistency no matter which choice we make
<scribe> ACTION: Ben summarize options discussed for issue 12 [recorded in http://www.w3.org/2006/02/13-htmltf-minutes.html#action12]
-> proposal for RDF/A Containers [Ben]
<danbri> (I quite strongly disagree that they have semantic value, except for rdf:Seq which rss needs)
Ben: I think there is a good match between OL, UL, and LI to RDF Containers
<danbri> (I commented in irc to avoid derailing the audio; sorry. I came late to this... might be wrong point to comment)
Ben: UL, OL, and NL can have specific RDF
types. I've been careful (see Section 3) that none of the triples previously
generated by RDF/A are affected by this proposal; e.g. see 3.3.2 example --
the about, rel, and href attributes
still generate the same triples as before; the UL and LI semantics only add
new triples. So I think this approach makes sense and is not too confusing.
Please send thoughts to the mailing list
Ben: next Monday is a US Holiday
Jeremy: regrets for next week; I'm on holiday
Steven: 2 weeks from today is Technical Plenary week
Ben: propose to meet Tuesday 21 March
RESOLVED: next meeting Tuesday 21 Feb 1400 UTC