RDFa Working Group

Minutes of 14 February 2011

Agenda
http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0120.html
Present
Ivan Herman, Shane McCarron, Toby Inkster, Nathan Rixham, Manu Sporny
Chair
Manu Sporny
Scribe
Manu Sporny
IRC Log
Original and Editable Wiki Version
Resolutions
  1. Modify RDFa Core, @vocab MUST NOT affect CURIE processing - accept Shane's proposal for resolving this issue. link
  2. The RDFa Core spec, in the XML+RDFa section should suggest that RDFa attributes are placed into the null namespace. Host Languages are allowed to place the RDFa attributes into a different namespace. link
  3. Adopt the text that Shane specified above changing the MUST to a SHOULD: For backward compatibility, RDFa Processors SHOULD... link
Topics
15:00:00 <manu1> Chair: Manu
15:00:00 <manu1> Present: Ivan, ShaneM, Toby, Nathan, Manu
15:00:00 <manu1> scribenick: manu1

(Scribe set to Manu Sporny)

15:00:00 <Zakim> +[IPcaller]

Zakim IRC Bot: +[IPcaller]

15:00:00 <webr3> Zakim, I am IPcaller

Nathan Rixham: Zakim, I am IPcaller

15:00:00 <Zakim> ok, webr3, I now associate you with [IPcaller]

Zakim IRC Bot: ok, webr3, I now associate you with [IPcaller]

15:00:00 <ivan> zakim, dial ivan-voip

Ivan Herman: zakim, dial ivan-voip

15:00:00 <Zakim> ok, ivan; the call is being made

Zakim IRC Bot: ok, ivan; the call is being made

15:00:00 <Zakim> +Ivan

Zakim IRC Bot: +Ivan

15:00:00 <manu1> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0120.html
15:00:00 <manu1> Topic: ISSUE-83: CURIEs must require colon

1. ISSUE-83: CURIEs must require colon

15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/83

http://www.w3.org/2010/02/rdfa/track/issues/83

15:00:00 <manu1> Manu: Nathan says that CURIEs should contain a ":"

Manu Sporny: Nathan says that CURIEs should contain a ":"

15:00:00 <manu1> Manu: Shane says that we never wanted @vocab to affect CURIE processing in the way that it does right now - it's a spec bug.

Manu Sporny: Shane says that we never wanted @vocab to affect CURIE processing in the way that it does right now - it's a spec bug.

15:00:00 <manu1> Shane: These issues are orthogonal.

Shane McCarron: These issues are orthogonal.

15:00:00 <manu1> Nathan: I agree, they're orthogonal - and if we accept @vocab affecting only Term processing, the issue goes away.

Nathan Rixham: I agree, they're orthogonal - and if we accept @vocab affecting only Term processing, the issue goes away.

15:00:00 <manu1> Ivan: The old CURIE spec allows a colon-less CURIE, right?

Ivan Herman: The old CURIE spec allows a colon-less CURIE, right?

15:00:00 <manu1> Ivan: If I have property="foo" - is it a Term or a prefix w/o a colon?

Ivan Herman: If I have property="foo" - is it a Term or a prefix w/o a colon?

15:00:00 <manu1> Shane: RDFa has never allowed a CURIE w/o a colon.

Shane McCarron: RDFa has never allowed a CURIE w/o a colon.

15:00:00 <manu1> Shane: The definition of CURIE permits a CURIE w/o a colon.

Shane McCarron: The definition of CURIE permits a CURIE w/o a colon.

15:00:00 <manu1> Ivan: If RDFa has never allowed a CURIE w/o a colon, then we should enforce that.

Ivan Herman: If RDFa has never allowed a CURIE w/o a colon, then we should enforce that.

15:00:00 <manu1> <div prefix="foafname: http://xmlns.com/foaf/0.1/name" property="foafname">Shane</div>

<div prefix="foafname: http://xmlns.com/foaf/0.1/name" property="foafname">Shane</div>

15:00:00 <tinkster> The <div> above is not the sort of CURIE without a colon that ISSUE-83 discusses.

Toby Inkster: The <div> above is not the sort of CURIE without a colon that ISSUE-83 discusses.

15:00:00 <ShaneM> This is what Mark proposed in his 'tokens' approach

Shane McCarron: This is what Mark proposed in his 'tokens' approach

15:00:00 <tinkster> The CURIE without a colon is a CURIE with no prefix, no colon, but with a suffix.

Toby Inkster: The CURIE without a colon is a CURIE with no prefix, no colon, but with a suffix.

15:00:00 <ShaneM> tinkster: yes

Toby Inkster: yes [ Scribe Assist by Shane McCarron ]

15:00:00 <tinkster> The definition of CURIE requires a colon whenever a prefix is given.

Toby Inkster: The definition of CURIE requires a colon whenever a prefix is given.

15:00:00 <ShaneM> tinkster: yes

Toby Inkster: yes [ Scribe Assist by Shane McCarron ]

15:00:00 <webr3> but not a prefix when a colon is given

Nathan Rixham: but not a prefix when a colon is given

15:00:00 <ShaneM> q+ to discuss the difference between a 'term' and a 'token'

Shane McCarron: q+ to discuss the difference between a 'term' and a 'token'

15:00:00 <manu1> Ivan: What's the difference between a prefix-less CURIE and Term?

Ivan Herman: What's the difference between a prefix-less CURIE and Term?

15:00:00 <manu1> Manu: The difference is artificial.

Manu Sporny: The difference is artificial.

15:00:00 <webr3> iva, all terms are current valid CURIEs too, you just can't use them

Nathan Rixham: iva, all terms are current valid CURIEs too, you just can't use them

15:00:00 <manu1> ack shaneM

ack shaneM

15:00:00 <Zakim> ShaneM, you wanted to discuss the difference between a 'term' and a 'token'

Zakim IRC Bot: ShaneM, you wanted to discuss the difference between a 'term' and a 'token'

15:00:00 <manu1> Shane: We debated this ad-nauseum - at the end of the day, we agreed to introduce terms as a way of having this abstraction.

Shane McCarron: We debated this ad-nauseum - at the end of the day, we agreed to introduce terms as a way of having this abstraction.

15:00:00 <manu1> Shane: If you want to re-open the issue - we could do that.

Shane McCarron: If you want to re-open the issue - we could do that.

15:00:00 <manu1> Ivan: Maybe the only thing we're missing here is that we don't have an attribute to define terms.

Ivan Herman: Maybe the only thing we're missing here is that we don't have an attribute to define terms.

15:00:00 <manu1> Ivan: Maybe we should have @prefix and @term.

Ivan Herman: Maybe we should have @prefix and @term.

15:00:00 <manu1> Shane: You can use @vocab, but that only helps if all of your terms are in the same URL.

Shane McCarron: You can use @vocab, but that only helps if all of your terms are in the same URL.

15:00:00 <webr3> q+ to say it wouldn't work

Nathan Rixham: q+ to say it wouldn't work

15:00:00 <manu1> ack webr3

ack webr3

15:00:00 <manu1> ack [IPcaller]

ack [IPcaller]

15:00:00 <Zakim> [IPcaller], you wanted to say it wouldn't work

Zakim IRC Bot: [IPcaller], you wanted to say it wouldn't work

15:00:00 <manu1> Nathan: It wouldn't necessarily work - you don't know if it's a relative IRI or a CURIE.

Nathan Rixham: It wouldn't necessarily work - you don't know if it's a relative IRI or a CURIE.

15:00:00 <ShaneM> about="lala"

Shane McCarron: about="lala"

15:00:00 <ShaneM> is that a 'curie that is only a prefix' or is it a 'relative uri' ?

Shane McCarron: is that a 'curie that is only a prefix' or is it a 'relative uri' ?

15:00:00 <manu1> Shane: If you happened to have define a prefix "lala" then you're boned.

Shane McCarron: If you happened to have define a prefix "lala" then you're boned.

15:00:00 <manu1> Manu: Ok, then that is a huge problem.

Manu Sporny: Ok, then that is a huge problem.

15:00:00 <manu1> Ivan: In RDFa, we cannot have colon-less CURIEs.

Ivan Herman: In RDFa, we cannot have colon-less CURIEs.

15:00:00 <manu1> Shane: Yes, I believe that's correct.

Shane McCarron: Yes, I believe that's correct.

15:00:00 <manu1> Shane: I referenced @vocab in the definition of CURIEs, there is this cross-pollination of something that shouldn't be there.

Shane McCarron: I referenced @vocab in the definition of CURIEs, there is this cross-pollination of something that shouldn't be there.

15:00:00 <manu1> Manu: Nathan, are you okay with this?

Manu Sporny: Nathan, are you okay with this?

15:00:00 <manu1> Nathan: Yes, for the most part - there are other orthogonal issues, but we can discuss that later.

Nathan Rixham: Yes, for the most part - there are other orthogonal issues, but we can discuss that later.

15:00:00 <ShaneM> ACTION: Clean up the cross-pollination of TERM, @vocab, and CURIEs

ACTION: Clean up the cross-pollination of TERM, @vocab, and CURIEs

15:00:00 <trackbot> Sorry, couldn't find user - Clean

Trackbot IRC Bot: Sorry, couldn't find user - Clean

15:00:00 <ShaneM> ACTION: ShaneM Clean up the cross-pollination of TERM, @vocab, and CURIEs

ACTION: ShaneM Clean up the cross-pollination of TERM, @vocab, and CURIEs

15:00:00 <trackbot> Created ACTION-63 - Clean up the cross-pollination of TERM, @vocab, and CURIEs [on Shane McCarron - due 2011-02-21].

Trackbot IRC Bot: Created ACTION-63 - Clean up the cross-pollination of TERM, @vocab, and CURIEs [on Shane McCarron - due 2011-02-21].

15:00:00 <manu1> PROPOSAL: Modify RDFa Core, @vocab MUST NOT affect CURIE processing - accept Shane's proposal for resolving this issue.

PROPOSED: Modify RDFa Core, @vocab MUST NOT affect CURIE processing - accept Shane's proposal for resolving this issue.

15:00:00 <webr3> +1

Nathan Rixham: +1

15:00:00 <manu1> +1

+1

15:00:00 <ShaneM> +1

Shane McCarron: +1

15:00:00 <ivan> +1

Ivan Herman: +1

15:00:00 <tinkster> +1

Toby Inkster: +1

15:00:00 <manu1> RESOLVED: Modify RDFa Core, @vocab MUST NOT affect CURIE processing - accept Shane's proposal for resolving this issue.

RESOLVED: Modify RDFa Core, @vocab MUST NOT affect CURIE processing - accept Shane's proposal for resolving this issue.

15:00:00 <manu1> Topic: ISSUE-82: The RDFa attribute namespace

2. ISSUE-82: The RDFa attribute namespace

15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/82

http://www.w3.org/2010/02/rdfa/track/issues/82

15:00:00 <manu1> Manu: So, how can we modularize RDFa 1.1?

Manu Sporny: So, how can we modularize RDFa 1.1?

15:00:00 <manu1> Ivan: How are these modifications going to be made?

Ivan Herman: How are these modifications going to be made?

15:00:00 <manu1> Manu: HTML4 DTD is a part of HTML+RDFa

Manu Sporny: HTML4 DTD is a part of HTML+RDFa

15:00:00 <manu1> Shane: Anybody can create a modularization document for XHTML.

Shane McCarron: Anybody can create a modularization document for XHTML.

15:00:00 <manu1> Ivan: Then do we say that attributes are in the null namespace?

Ivan Herman: Then do we say that attributes are in the null namespace?

15:00:00 <tinkster> FWIW, my library supports RDFa attributes in arbitrary namespaces. The code that calls the library tells it which namespace to use - which can be null. But it has to pick a single namespace for a document - you can't mix and match.

Toby Inkster: FWIW, my library supports RDFa attributes in arbitrary namespaces. The code that calls the library tells it which namespace to use - which can be null. But it has to pick a single namespace for a document - you can't mix and match.

15:00:00 <manu1> Shane: We can put stuff in the default namespace and the null namespace.

Shane McCarron: We can put stuff in the default namespace and the null namespace.

15:00:00 <manu1> Shane: Attributes are in no namespace - attributes can be namespaced, but generally they're not.

Shane McCarron: Attributes are in no namespace - attributes can be namespaced, but generally they're not.

15:00:00 <manu1> Ivan: This tells me that we don't have an issue here - we do whatever RDFa 1.0 had done - it's not different from RDFa 1.0.

Ivan Herman: This tells me that we don't have an issue here - we do whatever RDFa 1.0 had done - it's not different from RDFa 1.0.

15:00:00 <tinkster> Colonless elements can be in a namespace (via xmlns="..."); Colonless attributes cannot.

Toby Inkster: Colonless elements can be in a namespace (via xmlns="..."); Colonless attributes cannot.

15:00:00 <manu1> Manu: What about people that want to use @prefix in non-XHTML languages?

Manu Sporny: What about people that want to use @prefix in non-XHTML languages?

15:00:00 <manu1> Ivan: They're in the XHTML namespace.

Ivan Herman: They're in the XHTML namespace.

15:00:00 <tinkster> Following on from my "FWIW"... of course the default namespace the library uses is null, except for OpenDocument where it's the XHTML namespace.

Toby Inkster: Following on from my "FWIW"... of course the default namespace the library uses is null, except for OpenDocument where it's the XHTML namespace.

15:00:00 <manu1> Manu: xhv:prefix="foaf: http://xmlns.com/foaf/0.1/"

Manu Sporny: xhv:prefix="foaf: http://xmlns.com/foaf/0.1/"

15:00:00 <manu1> Manu: That's what someone would do ?

Manu Sporny: That's what someone would do ?

15:00:00 <manu1> Ivan: Yes, that's one possibility. Or they could use it in no namespace at all.

Ivan Herman: Yes, that's one possibility. Or they could use it in no namespace at all.

15:00:00 <ivan> <lala about="http:///" > is fine

Ivan Herman: <lala about="http:///" > is fine

15:00:00 <tinkster> <entry xmlns="http://www.w3.org/2005/Atom" content="This content attribute is in no namespace, even though the entry element is." />

Toby Inkster: <entry xmlns="http://www.w3.org/2005/Atom" content="This content attribute is in no namespace, even though the entry element is." />

15:00:00 <manu1> Shane: Looking at our spec, there is language in some of the XHTML family specs that talks about this - I don't think RDFa Syntax has that language - it defines a module in Chapter 9, but it doesn't do it in the way that we normally define modules. The text isn't there that would lock it down.

Shane McCarron: Looking at our spec, there is language in some of the XHTML family specs that talks about this - I don't think RDFa Syntax has that language - it defines a module in Chapter 9, but it doesn't do it in the way that we normally define modules. The text isn't there that would lock it down.

15:00:00 <manu1> Shane: For example, in the @role attribute spec...

Shane McCarron: For example, in the @role attribute spec...

15:00:00 <ShaneM> http://www.w3.org/TR/role-attribute/#host-language-conformance

Shane McCarron: http://www.w3.org/TR/role-attribute/#host-language-conformance

15:00:00 <manu1> Ivan: The only instance we know about, is how RDFa is used in ODF - it's in the XHTML namespace - they do it correctly.

Ivan Herman: The only instance we know about, is how RDFa is used in ODF - it's in the XHTML namespace - they do it correctly.

15:00:00 <manu1> Shane: Should processors work the way that Toby's does? Yes - is that what most people are going to implement - probably not.

Shane McCarron: Should processors work the way that Toby's does? Yes - is that what most people are going to implement - probably not.

15:00:00 <manu1> Shane: Should we test for it?

Shane McCarron: Should we test for it?

15:00:00 <webr3> so we can do <elem about="foo" xhv:about="bar"> ?

Nathan Rixham: so we can do <elem about="foo" xhv:about="bar"> ?

15:00:00 <ShaneM> well.. no. XHTML says that is an error

Shane McCarron: well.. no. XHTML says that is an error

15:00:00 <webr3> tfft

Nathan Rixham: tfft

15:00:00 <ShaneM> XHTML M12N says you cannot combine the no namesapce and namespaced versions on the same element

Shane McCarron: XHTML M12N says you cannot combine the no namesapce and namespaced versions on the same element

15:00:00 <manu1> Manu: I don't think this should be a processor conformance requirement - it complicates processors too much, for very little benefit.

Manu Sporny: I don't think this should be a processor conformance requirement - it complicates processors too much, for very little benefit.

15:00:00 <manu1> Shane: We agreed to introduce XML+RDFa - are we specifying that via an XHTML-style module? Or are we saying that there are RDFa attributes that go in the null namespace?

Shane McCarron: We agreed to introduce XML+RDFa - are we specifying that via an XHTML-style module? Or are we saying that there are RDFa attributes that go in the null namespace?

15:00:00 <manu1> Ivan: The latter

Ivan Herman: The latter

15:00:00 <manu1> Manu: The latter

Manu Sporny: The latter

15:00:00 <tinkster> I think this should be the host language's business. It a host language wants to put it into http://foocorp.example/blah namespace, that's their funeral.

Toby Inkster: I think this should be the host language's business. It a host language wants to put it into http://foocorp.example/blah namespace, that's their funeral.

15:00:00 <tinkster> (which doesn't mean that we don't need to discuss it - after all, we're trying to take the XHTML+RDFa host language through last call as well!)

Toby Inkster: (which doesn't mean that we don't need to discuss it - after all, we're trying to take the XHTML+RDFa host language through last call as well!)

15:00:00 <manu1> Manu: In the RDFa Core spec, in the XML+RDFa section - we suggest that RDFa attributes are placed into the null namespace. If a host language wants to place them into a difference namespace, they can do so.

Manu Sporny: In the RDFa Core spec, in the XML+RDFa section - we suggest that RDFa attributes are placed into the null namespace. If a host language wants to place them into a difference namespace, they can do so.

15:00:00 <ShaneM> For more on XHTML M12N attribute collections see http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_commonatts

Shane McCarron: For more on XHTML M12N attribute collections see http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_commonatts

15:00:00 <manu1> PROPOSAL: The RDFa Core spec, in the XML+RDFa section should suggest that RDFa attributes are placed into the null namespace. Host Languages are allowed to place the RDFa attributes into a different namespace.

PROPOSED: The RDFa Core spec, in the XML+RDFa section should suggest that RDFa attributes are placed into the null namespace. Host Languages are allowed to place the RDFa attributes into a different namespace.

15:00:00 <ivan> +1

Ivan Herman: +1

15:00:00 <manu1> +1

+1

15:00:00 <ShaneM> +1

Shane McCarron: +1

15:00:00 <webr3> +1

Nathan Rixham: +1

15:00:00 <tinkster> +1

Toby Inkster: +1

15:00:00 <manu1> RESOLVED: The RDFa Core spec, in the XML+RDFa section should suggest that RDFa attributes are placed into the null namespace. Host Languages are allowed to place the RDFa attributes into a different namespace.

RESOLVED: The RDFa Core spec, in the XML+RDFa section should suggest that RDFa attributes are placed into the null namespace. Host Languages are allowed to place the RDFa attributes into a different namespace.

15:00:00 <manu1> Topic: ISSUE-84: Cool URIs and HTTPRange-14

3. ISSUE-84: Cool URIs and HTTPRange-14

15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/84

http://www.w3.org/2010/02/rdfa/track/issues/84

15:00:00 <manu1> Manu: WWW TAG wants us to warn people that there is no follow your nose story (yet) for fragment identifiers.

Manu Sporny: WWW TAG wants us to warn people that there is no follow your nose story (yet) for fragment identifiers.

15:00:00 <manu1> Manu: There is no document that states how to interpret fragment identifiers via RFC3984 - no other document states this - they just want use to state that there is an issue

Manu Sporny: There is no document that states how to interpret fragment identifiers via RFC3984 - no other document states this - they just want use to state that there is an issue

15:00:00 <manu1> Ivan: This whole issue is completely transparent to RDFa - RDFa is a serialization.

Ivan Herman: This whole issue is completely transparent to RDFa - RDFa is a serialization.

15:00:00 <manu1> Ivan: It's an important issue, but it doesn't have to do w/ the RDFa spec.

Ivan Herman: It's an important issue, but it doesn't have to do w/ the RDFa spec.

15:00:00 <manu1> Shane: We could add language in there to explain this.

Shane McCarron: We could add language in there to explain this.

15:00:00 <manu1> "Using #foo with RDFa is a great thing. However you should note that the media type registrations (RFC 3986) don't yet talk about this practice."

"Using #foo with RDFa is a great thing. However you should note that the media type registrations (RFC 3986) don't yet talk about this practice."

15:00:00 <manu1> "If you care about the possibility that the element and the linked data node might have different properties, you should use different fragment ids."

"If you care about the possibility that the element and the linked data node might have different properties, you should use different fragment ids."

15:00:00 <manu1> <div id="currency" about="#currency">

<div id="currency" about="#currency">

15:00:00 <manu1> http://purl.org/money#currency

http://purl.org/money#currency

15:00:00 <manu1> <div id="ivan">This has nothing to do with Ivan</div>

<div id="ivan">This has nothing to do with Ivan</div>

15:00:00 <manu1> <div about="#ivan">This has something to do with Ivan</div>

<div about="#ivan">This has something to do with Ivan</div>

15:00:00 <manu1> Manu: So, this is a best practice issue.

Manu Sporny: So, this is a best practice issue.

15:00:00 <manu1> Nathan: The @id is a locally scoped name - it's part of the representation.

Nathan Rixham: The @id is a locally scoped name - it's part of the representation.

15:00:00 <manu1> Nathan: The two @about and @id point to two different thing.

Nathan Rixham: The two @about and @id point to two different thing.

15:00:00 <manu1> Nathan: What the TAG is saying is that when you follow your nose, in some cases you get the element - in other cases you get a semantic object.

Nathan Rixham: What the TAG is saying is that when you follow your nose, in some cases you get the element - in other cases you get a semantic object.

15:00:00 <manu1> What is this URL: http://example.org/foo#ivan ?

What is this URL: http://example.org/foo#ivan ?

15:00:00 <webr3> with @about two strings are concatenated to create a single name / logical constant -> "http://example.org#ivan" an opaque id

Nathan Rixham: with @about two strings are concatenated to create a single name / logical constant -> "http://example.org#ivan" an opaque id

15:00:00 <manu1> Ivan: It's a token - for a reasoning agent a URI is a token.

Ivan Herman: It's a token - for a reasoning agent a URI is a token.

15:00:00 <tinkster> id="ivan" and about="#ivan" should never identify different things. (the technical possibility exists for them to do so, but it's just broken)

Toby Inkster: id="ivan" and about="#ivan" should never identify different things. (the technical possibility exists for them to do so, but it's just broken)

15:00:00 <webr3> with @id it refers to a name resolved within the scope of the representation, it's essentially _:ivan

Nathan Rixham: with @id it refers to a name resolved within the scope of the representation, it's essentially _:ivan

15:00:00 <tinkster> webr3, no @id is globally addressable.

Toby Inkster: webr3, no @id is globally addressable.

15:00:00 <manu1> Ivan: if I want to use something that is not an element, then I should use two different fragment identifiers.

Ivan Herman: if I want to use something that is not an element, then I should use two different fragment identifiers.

15:00:00 <ShaneM> so you are saying about='#someToken' is effectively a named, externalized 'bnode' if there is no corresponding id='someToken' ?

Shane McCarron: so you are saying about='#someToken' is effectively a named, externalized 'bnode' if there is no corresponding id='someToken' ?

15:00:00 <ivan> <div id="ivan">afasdfa</div> <div about="#ivan-lala"></div>

Ivan Herman: <div id="ivan">afasdfa</div> <div about="#ivan-lala"></div>

15:00:00 <manu1> Manu: Yes, we'd want to do that

Manu Sporny: Yes, we'd want to do that

15:00:00 <webr3> tinkster, only as part of the dereferencing process.. you have to split on #, dereference left part, then right part is a locally scoped identifier within the representation - the two are dif

Nathan Rixham: tinkster, only as part of the dereferencing process.. you have to split on #, dereference left part, then right part is a locally scoped identifier within the representation - the two are dif

15:00:00 <manu1> Ivan: I think this is for the cookbook and not for RDFa Core.

Ivan Herman: I think this is for the cookbook and not for RDFa Core.

15:00:00 <manu1> Shane: If we can put this in the document in a short paragraph, let's do that.

Shane McCarron: If we can put this in the document in a short paragraph, let's do that.

15:00:00 <tinkster> Dereferencing has little to do with it.

Toby Inkster: Dereferencing has little to do with it.

15:00:00 <tinkster> I may not know what the URI <http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#references> identifies until I've dereferenced it, but the representations of <http://www.w3.org/2010/02/rdfa/sources/rdfa-api/> should not define it inconsistently.

Toby Inkster: I may not know what the URI <http://www.w3.org/2010/02/rdfa/sources/rdfa-api/#references> identifies until I've dereferenced it, but the representations of <http://www.w3.org/2010/02/rdfa/sources/rdfa-api/> should not define it inconsistently.

15:00:00 <ShaneM> ACTION: ShaneM Introduce a short paragraph about how frgids are not well defined by the corresponding RFCs and therefore why using them incorrect is potentially risky.

ACTION: ShaneM Introduce a short paragraph about how frgids are not well defined by the corresponding RFCs and therefore why using them incorrect is potentially risky.

15:00:00 <trackbot> Created ACTION-64 - Introduce a short paragraph about how frgids are not well defined by the corresponding RFCs and therefore why using them incorrect is potentially risky. [on Shane McCarron - due 2011-02-21].

Trackbot IRC Bot: Created ACTION-64 - Introduce a short paragraph about how frgids are not well defined by the corresponding RFCs and therefore why using them incorrect is potentially risky. [on Shane McCarron - due 2011-02-21].

15:00:00 <manu1> Topic: Ensuring xmlns backwards-compatibility, but not mentioning xmlns

4. Ensuring xmlns backwards-compatibility, but not mentioning xmlns

15:00:00 <manu1> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0104.html

http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0104.html

15:00:00 <manu1> Manu: There seemed to be general agreement on the mailing list that we shouldn't specify xmlns: as one of the RDFa attributes, but should instead deprecate it. This is partly due to the HTML WG decision to not support decentralized extensibility, and also because we now have @prefix and that seems to sit with people better than xmlns:

Manu Sporny: There seemed to be general agreement on the mailing list that we shouldn't specify xmlns: as one of the RDFa attributes, but should instead deprecate it. This is partly due to the HTML WG decision to not support decentralized extensibility, and also because we now have @prefix and that seems to sit with people better than xmlns:

15:00:00 <manu1> Manu: Shane, do you have any issues or concerns with this direction?

Manu Sporny: Shane, do you have any issues or concerns with this direction?

15:00:00 <manu1> Shane: Nope, sounds fine.

Shane McCarron: Nope, sounds fine.

15:00:00 <manu1> Side-discussion about the political aspects of MUST vs. SHOULD vs. MAY - general agreement that the nuance will be lost on most people. Important thing is to support backwards compatibility, but show that RDFa is moving away from xmlns:

Side-discussion about the political aspects of MUST vs. SHOULD vs. MAY - general agreement that the nuance will be lost on most people. Important thing is to support backwards compatibility, but show that RDFa is moving away from xmlns:

15:00:00 <ShaneM> ACTION: ShaneM to remove the definition of xmlns:prefix in section 5 and examples. Add prose in processing rules to ensure that processors are required to process xmlns:prefix for backward compatibility. Removed xmlns:prefix from all examples.

ACTION: ShaneM to remove the definition of xmlns:prefix in section 5 and examples. Add prose in processing rules to ensure that processors are required to process xmlns:prefix for backward compatibility. Removed xmlns:prefix from all examples.

15:00:00 <trackbot> Created ACTION-65 - Remove the definition of xmlns:prefix in section 5 and examples. Add prose in processing rules to ensure that processors are required to process xmlns:prefix for backward compatibility. Removed xmlns:prefix from all examples. [on Shane McCarron - due 2011-02-21].

Trackbot IRC Bot: Created ACTION-65 - Remove the definition of xmlns:prefix in section 5 and examples. Add prose in processing rules to ensure that processors are required to process xmlns:prefix for backward compatibility. Removed xmlns:prefix from all examples. [on Shane McCarron - due 2011-02-21].

15:00:00 <ShaneM> For backward compatibility, some Host Languages MAY also permit the

Shane McCarron: For backward compatibility, some Host Languages MAY also permit the

15:00:00 <ShaneM> definition of mappings via <aref>xmlns</aref>. In this case, the value to be mapped is

Shane McCarron: definition of mappings via <aref>xmlns</aref>. In this case, the value to be mapped is

15:00:00 <ShaneM> set by the XML namespace

Shane McCarron: set by the XML namespace

15:00:00 <ShaneM> prefix, and the value to map is the value of the attribute &#8212; a URI.

Shane McCarron: prefix, and the value to map is the value of the attribute &#8212; a URI.

15:00:00 <manu1> Manu: We should make it clear that we intend to remove xmlns: from RDFa and that authors shouldn't use it anymore.

Manu Sporny: We should make it clear that we intend to remove xmlns: from RDFa and that authors shouldn't use it anymore.

15:00:00 <ShaneM> For backward compatibility, RDFa Processors MUST also also permit the definition of mappings via <aref>xmlns</aref>. In this case, the value to be mapped is set by the XML namespace prefix, and the value to map is the value of the attribute &#8212; a URI. (Note that prefix mapping via <aref>xmlns</aref> is deprecated, and may be removed in a future version of this specification.)

Shane McCarron: For backward compatibility, RDFa Processors MUST also also permit the definition of mappings via <aref>xmlns</aref>. In this case, the value to be mapped is set by the XML namespace prefix, and the value to map is the value of the attribute &#8212; a URI. (Note that prefix mapping via <aref>xmlns</aref> is deprecated, and may be removed in a future version of this specification.)

15:00:00 <manu1> Manu: +1 for something to that effect.

Manu Sporny: +1 for something to that effect.

15:00:00 <manu1> Nathan: I think it should be "SHOULD"

Nathan Rixham: I think it should be "SHOULD"

15:00:00 <webr3> it wasn't made an ISSUE, i just proposed on list

Nathan Rixham: it wasn't made an ISSUE, i just proposed on list

15:00:00 <webr3> no issue number

Nathan Rixham: no issue number

15:00:00 <webr3> all text is in: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0104.html

Nathan Rixham: all text is in: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0104.html

15:00:00 <webr3> (exactly as discussed)

Nathan Rixham: (exactly as discussed)

15:00:00 <manu1> PROPOSAL: Adopt the text that Shane specified above changing the MUST to a SHOULD: For backward compatibility, RDFa Processors SHOULD...

PROPOSED: Adopt the text that Shane specified above changing the MUST to a SHOULD: For backward compatibility, RDFa Processors SHOULD...

15:00:00 <manu1> +1

+1

15:00:00 <ivan> +1

Ivan Herman: +1

15:00:00 <webr3> +1 (and remove xmlns:prefix def text)

Nathan Rixham: +1 (and remove xmlns:prefix def text)

15:00:00 <ShaneM> +1

Shane McCarron: +1

15:00:00 <manu1> RESOLVED: Adopt the text that Shane specified above changing the MUST to a SHOULD: For backward compatibility, RDFa Processors SHOULD...

RESOLVED: Adopt the text that Shane specified above changing the MUST to a SHOULD: For backward compatibility, RDFa Processors SHOULD...

15:00:00 <manu1> Topic: Supporting Terms in @prefix

5. Supporting Terms in @prefix

15:00:00 <manu1> Manu: We already discussed this earlier in the call

Manu Sporny: We already discussed this earlier in the call

15:00:00 <manu1> Manu: If we wanted to support prefix="foafname: http://xmlns.com/foaf/0.1/name". We can't do it because relative IRIs became ambiguous - are they a CURIE or are they a relative IRI? Having colon-less CURIEs is problematic because they're ambiguous vs. relative IRIs that may conflict w/ prefixes imported via @profile.

Manu Sporny: If we wanted to support prefix="foafname: http://xmlns.com/foaf/0.1/name". We can't do it because relative IRIs became ambiguous - are they a CURIE or are they a relative IRI? Having colon-less CURIEs is problematic because they're ambiguous vs. relative IRIs that may conflict w/ prefixes imported via @profile.

15:00:00 <manu1> Ivan: What happens when you do this about="foo" and then you pull in a prefix via a @profile that defines "foo" as a prefix? Your markup all of a sudden starts having a different meaning which is hard to debug.

Ivan Herman: What happens when you do this about="foo" and then you pull in a prefix via a @profile that defines "foo" as a prefix? Your markup all of a sudden starts having a different meaning which is hard to debug.

15:00:00 <manu1> General agreement that supporting tokens in @prefix is not possible to do in a way that is safe w/ the current design.

General agreement that supporting tokens in @prefix is not possible to do in a way that is safe w/ the current design.

15:00:00 <manu1> Topic: RDFa Error Vocabulary

6. RDFa Error Vocabulary

15:00:00 <manu1> Ivan: Do we want to integrate this into the document?

Ivan Herman: Do we want to integrate this into the document?

15:00:00 <manu1> Manu: I thought that we had agreed to do that?

Manu Sporny: I thought that we had agreed to do that?

15:00:00 <manu1> Shane: I thought so too.

Shane McCarron: I thought so too.

15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/wiki/Processor_Graph_Vocabulary

http://www.w3.org/2010/02/rdfa/wiki/Processor_Graph_Vocabulary

15:00:00 <manu1> Shane: That will go in an appendix?

Shane McCarron: That will go in an appendix?

15:00:00 <manu1> Ivan: Should it be in the rdfapg namespace? or just in the rdfa namespace?

Ivan Herman: Should it be in the rdfapg namespace? or just in the rdfa namespace?

15:00:00 <manu1> Manu: Same namespace.

Manu Sporny: Same namespace.

15:00:00 <webr3> ok

Nathan Rixham: ok

15:00:00 <manu1> Nathan: From a design perspective, it might be nicer to have them in different namespaces - but I'm easy.

Nathan Rixham: From a design perspective, it might be nicer to have them in different namespaces - but I'm easy.

15:00:00 <manu1> General agreement that we should put the RDFa processor graph vocabulary terms in the RDFa namespace.

General agreement that we should put the RDFa processor graph vocabulary terms in the RDFa namespace.

15:00:00 <manu1> Topic: ISSUE-77: Adding in extra blank node default subjects

7. ISSUE-77: Adding in extra blank node default subjects

15:00:00 <manu1> http://www.w3.org/2010/02/rdfa/track/issues/77

http://www.w3.org/2010/02/rdfa/track/issues/77

15:00:00 <manu1> Ivan: Don't really understand what he's asking for here?

Ivan Herman: Don't really understand what he's asking for here?

15:00:00 <manu1> Ivan: Adding in extra blank node default subjects as a feature of RDF Profiles vocabularies, i.e. to make vocabularies like OGP produce valid triples. Note that in some instances of RDFa processing the profile is retrieved anyways, so might as well make it do very useful things.

Ivan Herman: Adding in extra blank node default subjects as a feature of RDF Profiles vocabularies, i.e. to make vocabularies like OGP produce valid triples. Note that in some instances of RDFa processing the profile is retrieved anyways, so might as well make it do very useful things.

15:00:00 <manu1> Manu: Are we saying that the profile will have processing rules in addition to prefixes/terms?

Manu Sporny: Are we saying that the profile will have processing rules in addition to prefixes/terms?

15:00:00 <manu1> Ivan: Anything in the header would have a subject as a blank node.

Ivan Herman: Anything in the header would have a subject as a blank node.

15:00:00 <manu1> Ivan: I think that this is not possible because there are other statements in the header that we generate triples for - this would be a backwards compatibility issue.

Ivan Herman: I think that this is not possible because there are other statements in the header that we generate triples for - this would be a backwards compatibility issue.

15:00:00 <ivan> apage satanas

Ivan Herman: apage satanas

15:00:00 <manu1> Manu: We had discussed this before - you'd need a generic plug-in architecture for the RDfa processing rules - we don't want to go down that road (it would take forever to get it right, if that was even possible)

Manu Sporny: We had discussed this before - you'd need a generic plug-in architecture for the RDfa processing rules - we don't want to go down that road (it would take forever to get it right, if that was even possible)

15:00:00 <manu1> Manu: The result of that would be very difficult to understand for implementers - very meta.

Manu Sporny: The result of that would be very difficult to understand for implementers - very meta.

15:00:00 <webr3> " we can't at the minute "

Nathan Rixham: " we can't at the minute "

15:00:00 <manu1> Ivan: That's fine if we don't support this w/ me - it's asking for a /lot/ to happen.

Ivan Herman: That's fine if we don't support this w/ me - it's asking for a /lot/ to happen.

15:00:00 <manu1> Ivan: We're shifting towards a default profile - I don't expect Facebook would create this document even if we had this functionality.

Ivan Herman: We're shifting towards a default profile - I don't expect Facebook would create this document even if we had this functionality.

15:00:00 <ivan> ogp -> http://lalal.lal

Ivan Herman: ogp -> http://lalal.lal

15:00:00 <ivan> ogp -> http://lala.la#

Ivan Herman: ogp -> http://lala.la#

15:00:00 <ivan> http://lala.la#e

Ivan Herman: http://lala.la#e

15:00:00 <manu1> Ivan: If they add new properties, that's beyond our control.

Ivan Herman: If they add new properties, that's beyond our control.

15:00:00 <manu1> Shane: We were going to tell people that if they wanted to be in the default profile, they absolutely should not change the semantics of the vocabulary document over time.

Shane McCarron: We were going to tell people that if they wanted to be in the default profile, they absolutely should not change the semantics of the vocabulary document over time.

15:00:00 <manu1> General agreement that attempting to do this correctly would become a specification and implementation nightmare.

General agreement that attempting to do this correctly would become a specification and implementation nightmare.

15:00:00 <ivan> action: ivan to answer Harry on issue 77

ACTION: ivan to answer Harry on ISSUE-77

15:00:00 <trackbot> Created ACTION-66 - Answer Harry on issue 77 [on Ivan Herman - due 2011-02-21].

Trackbot IRC Bot: Created ACTION-66 - Answer Harry on ISSUE-77 [on Ivan Herman - due 2011-02-21].

15:00:00 <Zakim> -[IPcaller]

Zakim IRC Bot: -[IPcaller]

15:00:00 <ivan> zakim, drop me

Ivan Herman: zakim, drop me

15:00:00 <Zakim> Ivan is being disconnected

Zakim IRC Bot: Ivan is being disconnected

15:00:00 <Zakim> -ShaneM

Zakim IRC Bot: -ShaneM

15:00:00 <Zakim> -Ivan

Zakim IRC Bot: -Ivan

15:00:00 <Zakim> -manu1

Zakim IRC Bot: -manu1

15:00:00 <Zakim> Team_(rdfa)16:00Z has ended

Zakim IRC Bot: Team_(rdfa)16:00Z has ended

15:00:00 <Zakim> Attendees were +1.612.217.aaaa, ShaneM, manu1, [IPcaller], Ivan

Zakim IRC Bot: Attendees were +1.612.217.aaaa, ShaneM, manu1, [IPcaller], Ivan



Formatted by CommonScribe


This revision (#1) generated 2011-02-14 18:13:25 UTC by 'msporny', comments: 'Minor clean-ups and clarifications.'