See also: IRC log, previous 2008-02-07
<Steven> (Steven also sent his regrets for last week)
<Ralph> (I'll update last week's minutes, Steven)
<Steven> Probable regrets for next week too: returning from a FtF
Steven: coordination of Last Call schedule with Hypertext CG?
ACTION: Ben to email mailing list to think about last substantive issue on tracker: http://www.w3.org/2006/07/SWD/track/issues/6 [recorded in http://www.w3.org/2008/02/07-rdfa-minutes.html#action07] [CONTINUES]
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]
ACTION: Ben to add status of various implementations on rdfa.info [recorded in http://www.w3.org/2007/10/04-rdfa-minutes.html#action06] [CONTINUES]
ACTION: Manu write 2 new tests for img[@src] as subject [recorded in http://www.w3.org/2008/01/31-rdfa-minutes.html#action08] [CONTINUES]
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]
Mark: my changes to the Syntax document are
still in progress
... Shane has made the changes he is confident of
... my plan is to insure completion tomorrow
Shane: there's a diff-marked version, so change review should be quick
Ralph: responding to the comments with pointers to sections in the diff-marked version should suffice
Shane: I'll publish the new editors' draft when
ready
... and will send the response to Diego and Ed based on Manu's draft when the
new draft is up
ACTION: Shane send response to Diego and Ed review comments when new editors' draft is up [recorded in http://www.w3.org/2008/02/14-rdfa-minutes.html#action06]
Mark: I've skimmed Manu's draft response to the comments and don't see problems but until I finish the edits I won't know for sure
Manu: what about Ed's comment about reference
implementation?
... I proposed to cite the test suite
Ralph: at most the reference would be an informative one
Steven: citing the test suite in the Status
section would suffice
... also, there's no such thing in W3C as a "reference implementation"
... our test suite is not a conformance test
<msporny> rdfa-test-harness
RESOLUTION: link to test harness will appear in Status section
Shane: there are 3 open issues in the Syntax document
Manu: Ivan's issue about "useless" bnodes being generated
Mark: I plan to remove that
... I don't think we should generate useless statements
... the situation is when the object is a bnode and there are no further
references
Manu: this implies a change to the processing rules
Mark: yes, but in a minor way
Manu: not so minor for stream-based processors; requires look-ahead
Mark: use recursion instead; keep some state
that says whether to use the value you already have
... I will look at adding this and mail a proposal
... could leave the spec open-ended; leave it up to the implementation
... the extra triples serve no purpose but it's easier to leave them in the
algorithm
... implementations should not be penalized for dropping them
Shane: another issue about whitespace
normalization
... we currently refer to CSS2 for the algorithm
... I don't remember where the current text came from
Steven: I don't think we should collapse
whitespace at all
... the CSS rules are about presentation
... I think we should preserve whitespace in the triples because we don't
know what it is intended to represent
Manu: there are quite a few tests that exercise
this
... some of the tests do require that whitespace be normalized
Ralph: Ben has had some strong input on the whitespace issue
<msporny> rdfa-test-harness
Ralph: and in RDF/XML people have adopted usage styles that assume leading and trailing whitespace will be elided
Steven: that's fine -- that's what I call XML
normalization
... but the CSS rules have to do with presentation
Shane: Ben had done some experiments on deployed browsers
Manu: there's no such thing as preserving
whitespace in MSIE's DOM
... MSIE always returns normalized whitespace
... and I thought we'd resolved to leave it to the parser
Mark: how can we ensure consistency?
Shane: we'll end up with random triples
Mark: the test suite won't be able to
determine
... does SPARQL have a trim() function?
Manu: do the whitespace rules apply only to plain literals?
Mark: they'll need to apply to XMLliterals as well
Manu: my implementation leaves XMLliterals
as-is, only does whitespace normalization on plain literals
... and we've written the tests so there is no whitespace
... leading or trailing
... and embedded whitespace is just a single space char
Mark: if you have 10 lines of text you'd often write <span>...</span> with newlines and lots of spaces
Steven: see test 29
Mark: I thought we'd decided to write the test as if the XPath normalization would be done
<Steven> What about <pre property="my:poem">
Mark: the definition says something like "trim all leading and trailing whitespace and compress internal whitespace to a single space"
Steven: do newlines count?
Mark: I don't recall
... but I'm proposing to do whatever that function does
Shane: normalize-space(), I believe
<ShaneM> xpath#function-normalize-space
Steven: I'm a little dubious about removing internal whitespace
Mark: but we have MSIE that does normalize
whitespace
... this forces our hand
... so the only way we could deal with MSIE is to put normalization into our
spec
Shane: agree
Steven: that could be a bug in MSIE
Mark: the alternative is to leave it undefined and draw attention to implementors to trim space in the SPARQL query
Ralph: I really expect that the majority of RDF use cases will be happy with whitespace normalization
Steven: what if the internal whitespace is meaningful?
Shane: there's an XML Schema datatype that says 'preserve my whitespace'
Steven: will RDFa acknowledge this datatype?
Mark: XML rules itself does whitespace processing
Steven: root XML element can state
'preserve'
... I do acknowledge that there are few places where multiple embedded
whitespace is meaningful
... but I'd consider it a serious problem if there is no way to deliberately
include multiple spaces
Manu: we could add a datatype that says to preserve whitespace
Mark: that won't help; we have to either force
normalization into the language, which gets us to the lowest common
denominator
... or we leave it undefined and therefore users must be careful in their
SPARQL queries
Manu: we have to resolve this or we don't have a Last Call document
Ralph: I'd propose that we resolve to include normalization and explicitly note the resulting restriction in the Last Call document, asking for objectors to cite specific use cases
Mark: attribute values are not normalized
... and attribute values can contain newlines
Shane: the value of @content is a plain literal, which we're normalizing
Mark: MSIE with element content is the only
situation where we have a problem
... it's feeling more like a hack to me to specify normalization
everywhere
... but I also don't like a solution that treats attribute values differently
from element content
Manu: if people format their XML so that the markup is readable, will they be upset if the resulting value is not normalized?
Mark: shouldn't this be up to the implementation to decide how the value is to be used?
<Steven> <pre about "#me" property="my:address>21 Sandridge Road
<Steven> St. Albans, Herts
<Steven> UK</pre>
Mark: we're building on top of XML and XHTML
... the XML DOM does not do your normalization for you
... an implementor using this data has to normalize explicitly
Ralph: we could remove normalization from our spec and say it's the application's responsibility to normalize
Manu: then we'd have to change all the test cases to be sure not to have multiple whitespace
Shane: we could say nothing
Mark: we're building on XML, which uses
preserve
... so point out that not all implementations preserve whitespace
Steven: I support this
RESOLUTION: RDFa will state that whitespace is preserved and note that some implementations might not behave this way
Shane: next issue is difference between vocab URI and profile URI
Manu: any harm in making them identical?
Mark: conceptually there is no profile
[Steven departs]
Mark: @profile is supposed to indicate how to
interpret @name and @rel in meta and link
... we're creating a brand new language which is internally consistent
... the @profile is used as a flag to indicate the presence of RDFa
... could just as easily add an attribute to the root element
Ralph: so do you object to the way GRDDL uses @profile?
Mark: no, GRDDL wires itself into someone
else's use of @profile
... GRDDL hooks itself in behind the scenes
... it's only legitimate to use @profile to declare new @name and
@rel values
... so we come at it from another direction
... provide a URI for extensions to the HTML vocabulary
... use our vocab URI for that
... this is a legitmate @rel extension, so anyone could use this
... so @profile='vocab URI' is legitmate
Shane: indpendently, having 2 reserved URIs
that mean "RDFa [here]" is silly
... I think there should only be one and it should be the vocab
Ralph: I'm ok with that
... and it means that all the existing documents out there are not claiming
to have RDFa in them
Mark: using the vocab URI doesn't harm GRDDL usage
Ralph: [looks at Ben's home page]
... Ben uses the xhtml+rdfa DTD
Shane: also, please remove from the document
the green box that says "Ivan raised this"
... about unnecessary triples
Ralph: what about Last Call duration?
Shane: 6 weeks seems a long time
-> "RDFa Last Call period; consider TAG review?" [Ralph 2008-02-14]
Mark: the fact of existing implementations should help people be confortable
Manu: I'm fine with either 4 weeks or 6 weeks
Mark: I'd prefer a shorter period
Shane: 6 weeks seems long to me
RESOLUTION: the Task Force sees no need to have longer than 4 weeks Last Call period