RDFa Working Group Teleconference -- 22 Jul 2010

<manu> trackbot, prepare telecon

<trackbot> Date: 22 July 2010

On my way...

Aargh..."all circuits are busy now".

<Steven> Mark, did you notice new numbers?

@Steven: Football arrived yesterday...Reuben extremely happy!

<manu> Scribe: Mark

Heartbeat working drafts by end July 2010.

<Steven> s/@1,08Steven: Football arrived yesterday...Reuben extremely happy!//

Manu: We may be late on RDFa Core...need to publish every 3 months.

Steven: Technically, we need to publish /something/ every 3 months, but no necessarily each draft.

Ivan: Agree...according to process we're ok.

Shane: We can publish RDFa Core whenever we like, it's always up-to-date.

Manu: Not too worried about state of RDFa Core.
... But we haven't done anything on the API document for a while.
... Shane, could we have RDFa Core and HTML+RDFa ready to go?
... And then we could discuss the API document in the next month.
... Everyone ok with that?
... General nodding.

ISSUE-26

<manu> Mark: I'm concerned that we're creating a technology that we may not be able to agree on, without using up a lot of time. There are ways to do error mechanisms w/o needing an RDFa error vocabulary.

<manu> Mark: So the discussion may need to go back to whether or not we need to specify the error reporting mechanism in RDFa Core.

<manu> Ivan: Maybe we can keep the current formulation of processor graph and default graph.

<manu> Ivan: We should not define the details of what goes into the processor graph.

<manu> Ivan: If we put this formulation into the document, maybe the community will give us feedback as to whether or not they want an error reporting mechanism.

<Zakim> manu, you wanted to discuss vocabulary

<ShaneM> I don't care anymore

Manu: Problem is that each parser has a different mechanism for reporting errors.
... Would be great if Firefox's technique was the same as Ivan's Distiller.
... If we think that this would be useful not just to developers but end-users, then we should go to some lengths to define these values.
... We don't necessarily need to put the error vocabulary into RDFa Core, but it would be good if we did create a vocabulary.

Ivan: The problem is that realistically this is where opinions differ.
... So I have my version of the vocabulary...Benjamin wants an XML literal...Mark wants something EARL-based.
... So obtaining consensus is going to be time-consuming.
... Agree with Mark that this isn't so central that it should take up so much time.

<Zakim> manu, you wanted to discuss consensus

Ivan: So for the time being feel that we should just leave it open for now.

Manu: Not saying that this vocabulary should be discussed on the WG.

Ivan: Ok...happy to write that down.

Manu: Seems like something that is useful and warrants guidance.

<manu> Mark: I don't know if we need to have anything in RDFa Core about processor graphs. I think it makes sense in the RDFa API document.

<Zakim> ShaneM, you wanted to talk about how errors are handled in core

Mark: Would prefer to not see this in there at all, because I have a general feeling that things are getting more complicated.

Shane: What do we say in the core document about processing errors?

Ivan: We should retain the processor graph idea, so we only need to refer to that.
... We don't need to say what the triples look like.

Shane: If there is consensus on that then I'm fine.

Manu: There is other language in there about how to access this graph.

<ShaneM> The language is here: http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#processor-status

Manu: It looks like section 7.6.2 is what should come out.

Ivan: Think that the final warning in the list shouldn't be a must.
... (In the opening part of section 7.6.)

<ivan> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0130.html

Mark: Are we saying processors MUST implement all of this?

Manu: No. If you choose to implement this, then it must conform to this particularly arrangement.

<manu> PROPOSAL: A general error reporting mechanism should be described by RDFa Core, but the specifics of the RDFa Error Vocabulary are out of scope for RDFa Core per http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0130.html

<ivan> +1

<manu> +1

<Knud> +1

<Steven> +1

<ShaneM> +1

<manu> RESOLVED: A general error reporting mechanism should be described by RDFa Core, but the specifics of the RDFa Error Vocabulary are out of scope for RDFa Core per http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0130.html

Ivan: Don't forget to update tracker.

ISSUE 24

<Steven> issue-26?

<trackbot> ISSUE-26 -- Do we need an error reporting mechanism for RDFa? -- closed

<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/26

Manu: Shane put out a proposal in the last day or so.

<Steven> issue-24?

<trackbot> ISSUE-24 -- Should all terms be case-sensitive in HTML5 and XHTML? -- open

<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/24

Shane: This is actually Manu's proposal...I just provided the dextrous digits.
... Upshot of the proposal is to treat all terms as being compared case-insensitively.
... Solves the real problem I had which was that special-casing vocabularies seemed weird.
... Comparison of terms is case-insensitive.
... Languages can define terms.
... A profile should be declared to contain the terms, but they can be hard-coded.

Ivan: Clarifications: It's not a core part of the proposal but relates to last week's discussion -- the default vocabulary goes away.

Shane: Disagree. The spec says that a language can define a default vocabulary.

Ivan: Second thing is what to do with CURIEs that have an empty prefix.
... Shane's proposal resolves this, but would like to see a note in there to say that it's not a good idea.
... Final thing is to say that the set of terms in the current profile is fixed.
... I.e., if we add more terms then we need a new URI.
... Not sure how that will go down with HTML 5 and others.

Manu: Want to make it easy for implementers to define one set of terms.
... In the future HTML 5 will start adding terms, but it could take a while, so I don't think there will be an issue for a while.
... So we say that this is the default document for all RDFa processors. Then in a year or two we discover that there are other terms needed, and it's not too much of an issue to just add them.

<Zakim> manu, you wanted to discuss language documents that specify terms

Manu: However, if we need something dynamic for HTML 5 then we could create a document that contains a profile that must be loaded.

Ivan: I'm going to get into details here...but I think we need to.
... Conceptually XHTML will have its own profile document that lists the terms. Whether that's cached or not is besides the point.
... What happens if I have an XHTML document that has a profile document at the top?

Shane: That should override the default.

Ivan: Agree, but that should be made clear.

Shane: Have related question.
... If I load a profile on one element, and then load another in a child element, we get the result of both?

General nodding.

Shane: Since this is correct, then we have no way to clear the collection.
... @xml:lang="" clears the language...do we want the same feature?

Ivan: Give me the use-case.

Shane: I'm bringing in a part of a document, and I want to ensure that only the triples I want get included.
... Will raise this separately.

Ivan: If we're planning a new draft, we should also get the default profile document ready.

Manu: Isn't that the same as the XHTML Vocab document?

Shane: Yes...I'll update it.

Manu: Any objections to Shane's proposal?

<Steven> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0122.html

<manu> PROPOSAL: Adopt proposal for addressing ISSUE-24 (case-sensitive terms in HTML5) as posted to the mailing list: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0122.html

<ivan> +1

<manu> +1

<Steven> +1

<Knud> +1

<manu> RESOLVED: Adopt proposal for addressing ISSUE-24 (case-sensitive terms in HTML5) as posted to the mailing list: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0122.html

<ShaneM> +1

ISSUE 3

<Steven> issue-3?

<trackbot> ISSUE-3 -- Updating HTML5 coercion to Infoset rules -- open

<trackbot> http://www.w3.org/2010/02/rdfa/track/issues/3

Manu: Could either be very easy to resolve...or very difficult, depending on whether we involve the HTML WG.
... Issue raised some time ago by Henri, when he said that if we don't coerce the document into an infoset, then people won't know how to get attribute values.
... No-one had this problem, since many people had created JS parsers.
... There's a proposal now that HTML 5 parsing should preserve namespace values.

Ivan: It's one of those things where I understood it when you were explaining it...then it vanished.
... Is this something this WG has to deal with?
... And is the HTML WG prepared to look at this?

Manu: If we specify it, it will make it easier to extract the XMLNS terms.
... If it's rejected from HTML 5, then we have another path which is to specify it ourselves.
... As to whether the HTML WG is open to this, I don't know; an issue would be whether this breaks backwards-compatibility, and to answer that we'd need to speak with browser vendors.
... This is already in the spec and Henri hasn't raised any objections yet. But that may be because it's not on his (and/or Hixie's) radar.

<Zakim> ShaneM, you wanted to suggest a path

Manu: If it comes out of HTML 5 then we just do it the hard way, and look in both places for the values.

Shane: Admire your passion Eran Brokevich, but we have a solution, so not sure it's worth pushing on it.
... Since browsers won't know whether this breaks anything, then they could well be reluctant to make this change.
... "Let it go, Manu...let it go".

Manu: I think I'm going to push a bit longer.

(Would like to point out that we all laughed when Manu first suggested that HTML 5 should support RDFa, and that he was going to make it happen.)

<Steven> Regrets for next 4 weeks

Ivan: Regrets for next 4 weeks.

Steven: Regrets for next 4 weeks.

- DRAFT -

RDFa Working Group Teleconference

22 Jul 2010

Attendees

Contents

Heartbeat working drafts by end July 2010.

ISSUE-26

ISSUE 24

ISSUE 3

Summary of Action Items

Scribe.perl diagnostic output