RDFa Working Group Teleconference -- 20 May 2010

<manu> trackbot, prepare telecon

<trackbot> Date: 20 May 2010

<Knud> wow

<Knud> am I mute?

<dongmei> hi,good morning

<Knud> it's me!

<scribe> scribenick: Benjamin

<manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010May/0088.html

ivan: let's discuss ISSUE-6 with Shane

RDFa DOM API

manu: Mark and Manu discussed issues on integrating both RDFa DOM API proposals
... Benjamin is ok with the changes.

<manu> http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/

markbirbeck: Excellent work manu!

manu: changes are highlighted on the mailing list
... what we had was a low level API covering RDF types and some basic methods for retrieving triples
... Mark had many ideas to improve that and proposed to use this API even for other language formats (microformats, vcard, ...) than RDFa.
... added concepts of parser and store into the API and wrote about how to initialize the API
... We agreed on a much more gentle introduction of the document

Is tis the right direction?

ivan: wrote my oppinion in the mailing list.
... Finally, we should split parts of the document into several documents
... It's hard to understand the document because of the different levels that are mentioned.
... Ordinary users may be confused by too technical parts (e.g., store, parsers)
... in an Appendix a clean IDL specification of the API should exist
... The examples do not specify enough what is happening underneath

manu: We plan to have implementation details in section 3 and 4.

ivan: The document should be edited more as manual or reference guide.

markbirbeck: We can move several specifications and examples to be more self explanatory.

<manu> Benjamin: I'm wondering about who the audience is for this?

<manu> Benjamin: Maybe we want to have different sections for different readers.

ivan: main target group are developers but for a while users won't have any other document source than this specification

manu: The HTML WG also discuss on existing difficult specifications. Anyway specifications should read like an O'Reilly book.
... we have two target grooops, developers and users

<manu> ack [IPcaller]

tinkster: We should publish an extra document with examples that reads like a Primer

<Zakim> markbirbeck, you wanted to comment on end-users needing to be able to use specs.

markbirbeck: A Primer will set off pressure of this document. But a single document will preserve what is really meant to happen in the specification instead of having multiple documents like they exist for RDF(S).

<manu> Benjamin: Having read the document, I don't think we need to strip the document into separate documents.

<manu> Benjamin: We may want several sections Beginner Users vs. Advanced Developers vs. Implementers

<manu> Benjamin: I think it's okay to repeat ourselves throughout the document.

<markbirbeck> :)

<manu> Mark: I don't think that we'll repeat ourselves as much as you think we will.

manu: Can we publish a FPWD of this API in two weeks?

<markbirbeck> Mark: Agree with Benjamin that we shouldn't be scared of repeating ourselves in each section (with later sections being more detailed than previous ones). However, since we have some interfaces that are aimed at web developers only, and some interfaces that are aimed at more experienced programmers, then early sections will have different content to later ones.

ivan: If we integrate the issues we are discussing here into this document, we can do a FPWD.

tinkster: The API has a different shape than the current document.

ISSUE-8: Parsing CURIE lists

<manu> 2) ISSUE-8: Parsing CURIE lists (on Shane)

/sFPWD/FPWD

<manu> http://www.w3.org/2010/02/rdfa/track/issues/8

manu: We never specified handling whitespaces in RDFa specs.
... e.g. newlines tabs etc. are specified in XML.

<tinkster> Could we recommend that authors always use a single space character?

ivan: the host language (HTML, or XML dialect) has to specify handling whitespaces.

<tinkster> (as a SHOULD)

<tinkster> HTML5 it seems defers the definition of whitespace to Unicode.

\sFPWD\FPWD

manu: we may propose that RDFa refers to the host language for handling whitespaces.

\me thanks tinkster

<manu> PROPOSAL: RDFa defaults to the Host Language for what constitutes whitespace.

<manu> +1

<manu> PROPOSAL: RDFa defers to the Host Language for what constitutes whitespace.

<ivan> +1

<markbirbeck> +1

<manu> +1

<tinkster> XML just has 0x20, 0x0D, 0x0A and 0x09

<Knud> +1

<tinkster> +0.5

<tinkster> (i.e. XML is space, tab, carriage return and newline)

ivan: Did we leave whitespace handling unclear in the spec?
... We used a whitespace separated list in CURIE specification. That should be clear enough.

tinkster: Most languages leave whitespace handling and occurances open e.g. in XML and HTML5

<Steven> Apologies, I got my times mixed up.... :-(

tinkster: we are talking about whitespaces within attributes.
... the host language specs does not talk much about that

\swhitespaces within\whitespaces within

<manu> PROPOSAL: RDFa Core specification should specify what constitutes whitespace.

<tinkster> +1

<manu> +1

<ivan> And the definition in XML spec are S ::= (#x20 | #x9 | #xD | #xA)+

<ivan> +1

<Knud> +1

<markbirbeck> :)

<markbirbeck> +1

<Steven> :-)

<manu> PROPOSAL: RDFa Core specification should specify what constitutes whitespaces within attribute values.

<manu> RESOLVED: RDFa Core specification should specify what constitutes whitespaces within attribute values.

<markbirbeck> :)

<manu> 3) ISSUE-6: Invalid values in @datatype (on Ivan)

<manu> http://www.w3.org/2010/02/rdfa/track/issues/6

ivan: attributes with invalid values should behave like attributes with empty content

<ivan> @attribute="ILLEGALVALUE" is @attribute="" or no attribute at all

<manu> RDFa attributes containing all invalid values should be interpreted as those attributes with an empty attribute value.

<manu> PROPOSAL: RDFa attributes containing all invalid values should be interpreted as those attributes with an empty attribute value.

<ivan> +1

<tinkster> +1

<manu> +1

ivan: Shane will understand that

<Steven> "all" or "any"?

<markbirbeck> +1

<Knud> +1

<markbirbeck> all

<manu> RESOLVED: RDFa attributes containing all invalid values should be interpreted as those attributes with an empty attribute value.

tinkster: we should make an errata for RDFa 1.0 spec

<Steven> Errata are here: http://www.w3.org/MarkUp/2008/REC-rdfa-syntax-20081014-errata/

<manu> trackbot, issue Should RDFa allow relative URIs in any CURIE-based attribute?

<trackbot> Sorry, manu, I don't understand 'trackbot, issue Should RDFa allow relative URIs in any CURIE-based attribute?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<ivan> Does TERMorCURIEorURIs allow relative URI-s

<manu> trackbot, ISSUE: Does TermorCURIEorURI allow relative URIs?

<trackbot> Sorry, manu, I don't understand 'trackbot, ISSUE: Does TermorCURIEorURI allow relative URIs?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<manu> ISSUE: Does TermorCURIEorURI allow relative URIs?

<trackbot> Created ISSUE-27 - Does TermorCURIEorURI allow relative URIs? ; please complete additional details at http://www.w3.org/2010/02/rdfa/track/issues/27/edit .

<manu> ACTION: Shane to errata RDFa attributes containing all invalid values should be interpreted as those attributes with an empty attribute value. [recorded in http://www.w3.org/2010/05/20-rdfa-minutes.html#action01]

<trackbot> Created ACTION-29 - Errata RDFa attributes containing all invalid values should be interpreted as those attributes with an empty attribute value. [on Shane McCarron - due 2010-05-27].

<Steven> [ADJOURN]

- DRAFT -

RDFa Working Group Teleconference

20 May 2010

Attendees

Contents

RDFa DOM API

ISSUE-8: Parsing CURIE lists

Summary of Action Items

Scribe.perl diagnostic output