See also: IRC log, previous 2007-09-06
Ben: next TF telecon is 20 Sep
... the SWD WG telecon on Tuesday 25 Sep is critical to getting review before
the SWD f2f
... so all our issues should [result in] minor changes to the document right
now
Mark: how frozen is the f2f agenda?
Ralph: I don't think it's frozen yet
Ben: we've made some non-binding resolutions
that we're now depending on
... @instanceof, handling of @src, ...
... I think we should proceed with the non-binding resolutions as long as we
can
Manu: main issue is the spelling of
@instanceof
... haven't seen many alternatives being discussed recently in mail
Ben: yes, I just want to be clear on what we've finally resolved
Mark: should we refer to these non-binding resolutions in the document?
Shane: we said 6 weeks ago these were
non-binding
... that was 6 weeks ago
... let's move on at this point
Ben: I definitely want to move forward but I've made procedural mistakes in the past that people have called to attention
ACTION: Ben collect all the non-binding resolutions into a mail message and call for a vote [recorded in http://www.w3.org/2007/09/14-rdfa-minutes.html#action01]
Ralph: so our objective is to turn all non-binding resolutions into either closed issues or open issues and document the open issues in the published WD?
Ben: yes
Ralph: ... by next telecon
Ben: we should have a new editor's draft by
next Tuesday evening
... act as if the resolutions were resolved, revisit Thursday if not
resolved
Mark: will the Tuesday draft be the one we send to the WG?
Ben: by Tuesday night we should have a draft
that is ready to go to the WG except for the non-binding resolutions
... we can do limited edits on Friday
... we really want to send a document to the WG by Friday 21 Sep
Shane: the document we give to the WG on 21 Sep does not have to pass W3C pubrules, right?
Ralph: right, it's a draft for the WG to review to decide to request W3C publication
Ben: we also need the XHTML2 Working Group to
formally decide to publish the document
... since it's joint work of the two WGs
Shane: we're not going to have a shortname and issue the W3C request for publication on 21 Sep, right?
Ralph: right
ACTION: Ben to write up @instanceof referring to other subjects [recorded in http://www.w3.org/2007/09/06-rdfa-minutes.html#action15] [DONE]
ACTION: Michael look for a more semantically correct predicate for tests 42-45 [recorded in http://www.w3.org/2007/09/06-rdfa-minutes.html#action14] [CONTINUES]
ACTION: Michael make sure to confirm a design for checking that the ASK SPARQL queries evaluate (yes/no) [recorded in http://www.w3.org/2007/09/06-rdfa-minutes.html#action07] [CONTINUES]
ACTION: Ben add an isbn: resource example to the Primer to illustrate @resource overriding @href [recorded in http://www.w3.org/2007/08/30-rdfa-minutes.html#action08] [CONTINUES]
Ben: I worked on this but had trouble fully integrating, so still in progress
Mark: I did include an isbn: example in the Syntax doc
Ben: isbn: was a simple use case for @resource
overriding @href
... I'm still working on a convincing case for @resource overriding @src
Mark: FOAF has an "online ID"
... something that isn't meant to be a clickable link; just an identifier
ACTION: [DONE] Ben send mail to the TF list when the Primer editors' draft is ready for the TF to read [recorded in http://www.w3.org/2007/08/30-rdfa-minutes.html#action14]
ACTION: Ben to look into Science Commons use case [recorded in http://www.w3.org/2006/12/11-htmltf-minutes.html#action04] [CONTINUES]
Ben: the Science Commons use case may be becomming less relevant to this TF but let's keep this action open
ACTION: Ben to recontact implementors Elias, MarkB, triplr [and Fabien] and post their implementations to http://esw.w3.org/topic/RDFa#Implementations [recorded in http://www.w3.org/2007/08/02-rdfa-minutes.html#action09] [CONTINUES]
Ben: I want to add those to the implementations page
ACTION: Ben to work test cases 31 and 32 into primer [recorded in http://www.w3.org/2007/08/16-rdfa-minutes.html#action14] [CONTINUES]
ACTION: Ben, Mark, Elias, and other implementors to add xml:lang support [recorded in http://www.w3.org/2007/08/23-rdfa-minutes.html#action11] [CONTINUES]
Mark: I've implemented xml:lang but not wrapping
ACTION: Michael to create "Microformats done right -- unambiguous taxonomies via RDF" on the wiki [recorded in http://www.w3.org/2007/08/23-rdfa-minutes.html#action06] [CONTINUES]
Ralph: none appear to be critical path for the editors' drafts
Ben: right
-> RDFa Syntax document technical issues
-- Conformance Section
Shane: W3C specs are now expected to have a
conformance section
... defines what it means to be conformant
Ben: Mark and I appear to have a bit of a disagreement on what it means to be conformant
Shane: that's exactly why we write a conformance section
Mark: I'm trying to achieve a particular set of
use cases
... the QA people will ask us how we test conformance, so conformance should
be testable
... there's a question about whether I'm non-conformant if I generate extra
triples
Ben: the issue is "Can an RDF-conformant parser generate additional triples than those specified in the Syntax specification?"
Ralph: I thought we'd resolved that issue
ACTION: Ben research whether "Can an RDF-conformant parser generate additional triples than those specified in the Syntax specification?" is an already closed issue [recorded in http://www.w3.org/2007/09/14-rdfa-minutes.html#action12]
Mark: we'll need to work out how we define conformance
Shane: every assertion in the document applies to conformance
ACTION: Shane create a conformance section [recorded in http://www.w3.org/2007/09/14-rdfa-minutes.html#action13]
Shane: the debate about "what does it mean to conform" is a debate about the entire document
-- will xml:base work?
Ben: the main idea is that if the host language
doesn't support xml:base then it doesn't make sense for RDFa to require it
... and since XHTML1 doesn't support xml:base, we don't depend on it
... if the host language -- e.g. XHTML2 -- does support xml:base then RDFa
will use it
... so we resolve URIs the same way as the host language
... and BASE in XHTML1 is called out specifically in the Syntax document
... the issue resolution is meant to leave the door open to XHTML2
Mark: XHTML modularization also leaves open the
door to other languages
... should I remove the language about xml:base that's in the editor's draft
now?
Ben: I think so
... this document is about RDFa in XHTML1
Shane: we already have a document about RDFa
modularization and could move the xml:base words to there
... or put it into an appendix
Manu: reading the xml:base words from a newcomer's perspective, it appeared to be coming from left field; I didn't understand why that language was there in the document
Ralph: I move to put it into an appendix
Ben: I'm worried about how this document will be accepted by other folks
Mark: I'm talking about consistency and how this module will be used in other languages
Ben: this Syntax document is not a module
specification
... for folks working with XHTML1.1 and writing a parser for that, the
language about xml:base is not relevant
<ShaneM> The module is defined in http://www.w3.org/MarkUp/2007/ED-xhtml-rdfa-20070811/
Mark: it _is_ possible for xml:base to appear in an XHTML1.1 document
Manu: taking it out of the normal flow of the document and putting it into the end is sufficient
RESOLUTION: move xml:base discussion to an appendix
<benadida> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Sep/0142.html
-- SAX Processing
Mark: good idea to find one, but I don't have
one at the moment
... since I say "SAX-like", I'd better find one or clarify
ACTION: Mark find a reference for SAX or clarify the "SAX-like" language [recorded in http://www.w3.org/2007/09/14-rdfa-minutes.html#action14]
-- datatypes
Shane: the question was "What datatypes are allowed to be specified?"
Mark: there's really no limit
Manu: my understanding was that anything in XSD could be used
Mark: and any other datatype URI
Ben: that's also what I understood
Mark: in terms of the abstract syntax, it's any datatype URI
RESOLUTION: RDFa does not restrict datatypes
-- definition of canonicalization
Ben: this is complicated by the question of whether the DOM is used to resolve whitespace
Shane: my gut feeling is that we should not pay
any attention to the fact that XHTML sets xml:whitespace to 'preserve'
... XHTML says that whitespace is preserved, so after processing all the
whitespace is present, which strictly means that the whitespace should be
available to the RDFa processor
... but in practice all the implementations strip out the whitespace
Mark: we'd had a long discussion in XHTML2 and I thought we'd already agreed that XHTML1 should not have chosen 'preserve'
Shane: I don't think that's true
Mark: still, I don't quite know how we do
this
... unless we create a profile that does not include xml:space=preserve
Shane: do you believe we can access this data from the client side?
Mark: no, implementation-wise I agree [that
whitespace is not preserved]
... but how can we undo what XHTML1 has chosen? How do we get rid of the
whitespace that XHTML1 is requiring us to preserve?
... we could require the parser to strip the whitespace
Shane, Ben: yes, tell the parser to strip it
Shane: defer to the CSS definition
... I will grab the text from there
Mark: we don't want to be inconsistent [across
implementations] -- that was Fabien's problem
... with test case 29
<ShaneM> XHTML M12N says: On rendering, whitespace is processed according to the rules of [CSS2].
Ben: do the CSS rules only concern whitespace or does it cover other canonicalization questions?
Mark: only whitespace
<ShaneM> so we just say "for processing purposes of XML Literals, whitespace is processed according to the rules of [CSS2]"
Manu: the CSS rules are quite heavy. It's not necessarily clear which ones we're citing
Shane: just the whitespace rules
Ben: from the implementation point-of-view, all the parser needs to do is access the DOM
Shane: yes, that's why we want to make this choice for the client. On the server side you may have to do more work
Mark: it's all literals, not just XML Literals
RESOLUTION: for processing purposes of literals, whitespace is processed according to the rules of [CSS2]
Shane: yep; that's what I meant
Ben: Elias' point was also about stripping elements from markup when @datatype=""
Mark: that was Fabien's question too
... we've defined rules for converting child elements
... Fabien asked for clarification of those rules
Ben: FireFox DOM has a notion of 'text content'; is that a standard method?
Mark: I think it is defined in the XML DOM
... I
... I'll add better language in the next draft
ACTION: Mark find language for canonicalization of markup in plain literals [recorded in http://www.w3.org/2007/09/14-rdfa-minutes.html#action15]
-- @lang
Shane: we've resolved to use xml:lang, right?
Ben: XHTML1.1 only uses @xml:lang
RESOLUTION: RDFa in XHTML1.1 uses @xml:lang and does not use @lang
Mark: are we sure we ignore @lang in XHTML?
Shane: @lang is not in the DTD
Ben: points 6 and 7 in issues mail left to separate discussions?
-- @instanceof behaviour
Mark: Ivan and Elias have also stated a
preference for @instanceof applying to the element in which the attribute
appears
... I find it confusing to make @instanceof apply to the child
Ben: perhaps we can resolve this in mail
Mark: this was a reflection of a long practice
for LINK being a child of a node
... this got grey when we reintroduced chaining
... we ended up with @instanceof referring to the child, even though @class
didn't work this way
Ben: I think there are reasonable use cases for
either interpretation
... but an author who puts too many attributes on a single element is just
asking for trouble
... an author who clearly wants separate nodes can make a child
Mark: yes, and I think that approach is much clearer; implicitly creating a bnode is confusing
Ben: when @about and @instanceof are the only
attributes, the type applies to the @about
... when @about, @resource and @instanceof all appear, that's where Mark and
my interpretations differ
Mark: yes
... this turns out to be a minor change to the processing model, so the
decision won't have a huge impact on the document
Ralph: yes, making @resource change the interpretation of @instanceof feels like a huge leap
Ben: but from the other direction, it's @about that is changing the interpretation
Mark: yes, and our focus is on the "aboutness"
Ben: it's a matter of the way you think about it; adding @resource to @about or adding @about to @resource
Mark: if you can come up with a good way of
picturing what you're describing, you may convince lots of people
... a clear conceptual model may convince everyone
Ben: everyone OK with Tuesday night for everything we're going to ask the WG to review?
Shane, Mark: yes
Ben: we'll work to resolve questions 6 and 7 by email
[adjourned]
[un-scribed discussion of conformance w.r.t. additional triples ...]