See also: IRC log, previous 2008-03-27
Ben: propose not to discuss TAG's feedback on CURIEs here in this telecon
Ben: TAG's feedback is directed to XHTML2 WG and not RDFa
ACTION: Ben and Ralph to review response to Christian Hoertnagl. [recorded in http://www.w3.org/2008/03/27-rdfa-minutes.html#action07] [CONTINUES]
ACTION: [DONE] Ben to ask Shane about DOCTYPE and validation. [recorded in http://www.w3.org/2008/03/27-rdfa-minutes.html#action10]
Ben: we were talking about changing 'SHOULD have a DOCTYPE' to 'MAY have a DOCTYPE'
Ben: Shane made the point that 'SHOULD' is already optional, so why change anything?
Manu: SHOULD is stronger than MAY
... it says "you really really should do this unless you have a good reason
not to'
Shane: we're saying that if you want to validate your document you SHOULD have a DOCTYPE
<Steven> But don't we use the DOCTYPE for follow your nose?
Ben: what if in the next year the W3C validater
no longer requires DOCTYPE?
... do we make our spec dependent on the current state of validation?
<Steven> How about: SHOULD use a DOCTYPE, but if not then version="XHTML+RDFa 1.0"
Mark: SHOULD has wiggle room
Shane: MAY is a very strange thing to say when
you're talking about document conformance
... MAY is used to talk about implementation conformance
Ben: I think we should leave it as SHOULD
... and possibly add a note commenting about validation
<Steven> I am happy with either
Ralph: what does XHTML1 say about DOCTYPE?
Shane: DOCTYPE is required in XHTML 1.1 and SHOULD in XHTML 1.1 2nd edition
Ben: so we shouldn't weaken the requirements
from the host language
... our response to Tim can point to the host language
<msporny> +1 for SHOULD
<Steven> I wish there were an alternative for defining character entities
<benadida> PROPOSE: that we respond to TimBL regarding DOCTYPE as follows 'SHOULD leaves enough wiggle room for when validation no longer requires DOCTYPE'
<ShaneM> And also point out that "SHOULD" is optional already.
<msporny> +1
Steven: do we want to say that if there is no DOCTYPE then there must be @version="XHTML+RDFa"
Ralph: no. I thought we agreed last week that we'd update the namespace document
Shane: no objection to updating the namespace
document but it does nothing for announcement
... what does something for announcement is if we agree that all XHTML
languages have these new attributes
... and that has impact outside the XHTML2 WG
Steven: I think we're capable of changing the
namespace document
... we could even turn the namespace document into an RDFa document
<benadida> PROPOSE: that we respond to TimBL regarding DOCTYPE as follows 'SHOULD leaves enough wiggle room for when validation no longer requires DOCTYPE', that we *not* require HTML version=, and that we update the XHTML namespace document accordingly.
<Steven> +1
RESOLUTION: we respond to TimBL regarding DOCTYPE as follows 'SHOULD leaves enough wiggle room for when validation no longer requires DOCTYPE', that we *not* require HTML version=, and that we update the XHTML namespace document accordingly.
ACTION: [DONE] Manu correct test 11 [recorded in http://www.w3.org/2008/03/27-rdfa-minutes.html#action12]
ACTION: [DONE] Mark to double check the _:a bnode notation in RDFa syntax [recorded in http://www.w3.org/2008/03/27-rdfa-minutes.html#action11]
Mark: done during last week's call
... Shane noted that it was not mentioned anywhere but then we found it
Shane: it's mentioned in an informative section and should be moved up to the normative processing rules
Mark: you have to piece together information from 3 parts
ACTION: Mark to move _:a bnode notation to normative section [recorded in http://www.w3.org/2008/04/03-rdfa-minutes.html#action05]
ACTION: Ben followup with Fabien on getting his RDFa GRDDL transform transferred to W3C [recorded in http://www.w3.org/2007/11/15-rdfa-minutes.html#action01] [CONTINUES]
Ben: Fabien did update his transform but it's not yet under W3C software license on the W3C site
ACTION: Ben to follow up on media type discussion with Steven, Ralph, and TAG [recorded in http://www.w3.org/2008/03/20-rdfa-minutes.html#action08] [CONTINUES]
ACTION: Ben to respond to issue 87 [recorded in http://www.w3.org/2008/02/28-rdfa-minutes.html#action09] [CONTINUES]
ACTION: Manu to enable EARL output in RDFa Test Harness [recorded in http://www.w3.org/2008/03/13-rdfa-minutes.html#action13] [CONTINUES]
Manu: almost done. I have to respond to some comments from DanC
ACTION: Mark/Shane include issue 89 correction in Changes section [recorded in http://www.w3.org/2008/03/06-rdfa-minutes.html#action11] [CONTINUES]
ACTION: Michael to create 'RDFa for uF users' on RDFa Wiki [recorded in http://www.w3.org/2008/03/13-rdfa-minutes.html#action12] [CONTINUES]
-> issue 102
<benadida> Last Call Comment: Better name than 'instanceof' is needed [John Boyer 2008-03-17]
Ben: poll around the table?
Steven: I'm in favor of a new name. I posted a list of ~50. I didn't propose a favorite
Mark: [each of us] needs to argue in favor of one position
Steven: I'd be happy with @kind
Ben: from mail, @kind and @typeof seem to be bubbling up high
Steven: @typeof has the same prior use issues that @instanceof had
Mark: lots of suggestions have been made and
each has had problems.
... I think @instanceof is fine
... the only alternative that works for me is @typeof
... people know what "type" means even if they're not fully conversant in set
theory
Manu: @typeof
... I consider how easy it is to explain to a normal Web developer
... I've never really liked @instanceof
<Steven> <p contains="cal:Vevent">
Ralph: @typeof feels like the wrong
relationship direction to me from an RDF point of view
... but I don't feel strongly between @instanceof and @typeof
... I think we could justify either
Shane: @typeof is OK with me
Steven: we're addressing the microformats
crowd
... it's nice if the words suggest something without having to refer to RDF
concepts
Mark: but we should be careful not to say
something that's wrong in the world of RDF concepts
... e.g. 'contains' doesn't have an RDF interpretation
Ben: both @kind and @typeof are superior to
@instanceof
... I'm ok with @typeof but single-word things are nice
... @kind is less likely to receive complaints
... and telling people it's 'kind like mankind'
<Ralph> [Personkind :) ]
Mark: I don't doubt that @kind can be
explained
... and isn't this very close to the Germanic ?
... do we even want to have to send the one-line 'kind like mankind' mail?
... I think @kind would generate more questions than @typeof
Steven: I prefer @typeof to @instanceof
PROPOSE: change @instanceof to @typeof
<msporny> +1
<Ralph> no objection
<ShaneM> +1
<markbirbeck> +1
<benadida> +1
<Steven> abstain
RESOLUTION: change @instanceof to @typeof
ACTION: Mark and Shane update Syntax to change @instanceof to @typeof [recorded in http://www.w3.org/2008/04/03-rdfa-minutes.html#action12]
ACTION: Manu update test cases to change @instanceof to @typeof [recorded in http://www.w3.org/2008/04/03-rdfa-minutes.html#action13]
<Steven> I abstain because I think it is a bad choice, but I don't expect anything I suggest will gain traction, since I've already tried so many
Ben: does this require another Last Call?
Ralph: if we believe there will be objections then it's less costly to do another Last Call than to discover objections in CR
Shane: we should get Yahoo!'s feedback
<ShaneM> I would like to see a new test case that uses @instanceof and should fail
ACTION: Ben write to Micah for feedback on change to @typeof [recorded in http://www.w3.org/2008/04/03-rdfa-minutes.html#action14]
-> issue 101
Ben: "late binding" is better terminology than "garbage collection", as Shane noted
<ShaneM> I have to leave, but for the record I am in favor of generating these triples even if they are meaningless. Or rather, I don't mind either way.
[Shane departs]
Mark: the irony is frustrating as it only comes
from Ivan's notes
... it was purely by chance that I discovered that by moving something
outside of the recursion we could eliminate these triples
... this came as a side-effect of fixing a bug uncovered during SWD WG
review
... it's incorrect to say this is impossible to handle this in XSLT
... I am, however, worried about introducing other problems if we change
this
Ben: my parser is conformant in every way except this one; I've just never made this change
Manu: I prefer keeping the current rule set as
is
... I don't see a use case for all these nested @rels
... I don't see a use case for building up triples with all these meaningless
bnodes
... I don't see sufficient benefits to this change
Mark: while I agree with Manu, there's an
opposing view
... one of the consequences of the error that I fixed is that when there are
multiple @property as the child of a hanging triple you repeat the hanging
thing
... you could argue that if we're leaving things as they are then it's not a
big leap to asking us to eliminate all redundant triples
... I wonder if we're setting ourselves up to something
... it may be more honest to admit there's stuff lying around
Ben: it could seem inconsistent to keep this flag here to get rid of redundant triples yet keep duplicate triples elsewhere
Steven: I don't have a strong feeling either way
Ralph: I'm concerned that if we make this change we should do more testing
Ben: if this is an issue that is really needling a few people and it takes us a few weeks to test, that seems reasonable to me
Mark: the extra complexity in the rules is not
to do with this issue but to deal with a bug in the recursion spotted by the
SWD review
... I noted that my fix to the recursion could also address something Ivan
noted
Ben: the complexity may just be a perception
... taking 3 weeks to resolve this may be worthwhile
Mark: the completion of incomplete triples can
be made conditional
... could make a tiny change to always complete triples
... this might have less risk of new bugs but wouldn't produce a big
simplification
Manu: we should be very careful about why we're
making this change
... and I don't see that a change here will reduce the complexity of the
rules
... the only argument [that persuades me] is that people will be building up
their triples in this particular way by creating lots of bnodes
... if it doesn't simplify the rules then it won't simplify the
implmentation
Ben: but we have an explicit comment from Micah to that effect
Mark: but [Micah's comment] mis-identifies
where the complexity is coming from
... Micah is seeing the recursion as complex in order to get rid of extra
triples
... but the recursion is there to handle intervening markup
... my reference to 'extra triples' in the spec is misleading people to think
that's the reason for the recursion
<Steven> Regrets for next week
<Steven> gotta go
[Steven departs]
Mark: I still think it's an easy change but as we all know, any change brings a risk of introducing new bugs
Ralph: and I'm ok with 3 weeks to test if we believe the change is useful
Ben: I'm also ok with 3 weeks
... I feel strongly that this could be misleading
... my concern was always about authors and what could be confusing to
them
... DanBri seems to think this is actually wrong
... Steven and Shane don't seem to feel strongly either way
Mark: if there's no other reason to repeat Last Call, I'd leave the spec as is
Ralph: I'm mostly concerned about leaving
adequate testing time if we make this change
... in particular, we won't likely get a new cleanroom implementation
Ben: I'm willing to do a new cleanroom implementation
Manu: I don't see a strong reason to change
... but adding 3 weeks to the schedule bothers me
[Mark departs]
<benadida> Last Call Comment: garbage collecting "useless" triples [Ivan 2008-03-20]
PROPOSED: Modify processing rules per ISSUE-101 to process and produce triples consisting of only bnodes
Ralph: Shane and Mark seem to lean on the side
of keeping the triples
... Steven seems to be abstaining
... I'm ok with the change if Ben does a cleanroom implementation and we add
time to test
<benadida> +1 to proposal
<msporny> +1, only if the group is okay with extending testing for another 3-4 weeks and Ben has a cleanroom implementation. I don't particularly agree that the change is helpful, but others feel that this will help authors.
RESOLUTION: Modify processing rules per ISSUE-101 to process and produce triples consisting of only bnodes
Ralph: we don't actually know if Steven, Mark, and Shane agree to the +3 weeks so they'll have to object if that's the case
[adjourned]