<trackbot> Date: 08 December 2011

<scribe> Scribe: manu1

Any updates/changes to Agenda? None.

ISSUE-114: HTML5 coerces @href/@src values to URLs instead of IRIs

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

manu1: We have two alternatives...

niklasl: Is it viable to de-percent encode?

manu1: I think so

niklasl: If somebody uses a percent-encoded URI in triples... how does that work out?

manu1: Our strategy to this point has been to just copy the data from the attribute w/o processing.

<niklasl> <http://example.org/å> = <http://example.org/%C3%A5>

manu1: We could keep doing that - and just warn people that they can't express all IRIs in HTML5 in @href and @src.

niklasl: Encountering both in data, expecting them both to be IRIs is a possibility, I think.

gkellogg: If we do percent decoding, we're the only ones that do - they do escape decoding of literals/URIs in order to remove the escapes... but they don't do the same for percent-encoding.
... What is the least harm? Is it really likely that authors are going to try to represent two URIs differently?
... percent-decoding might get to authors original intent...
... Graph produced by RDFa may be different from the one generated from TURTLE... no silver bullet to this problem.
... If @href and @src is not percent-decoded... we need to include @resource in RDFa Lite... otherwise, no way to express unicode object in HTML5.

manu1: Or, we could say that RDFa Lite cannot solve this particular use case.

gkellogg: I wonder if percent-decoding was considered in other groups.

manu1: We could provide both options in the RDFa Core spec... mark it up with a warning, then get feedback from HTML WG, WHAT WG, RDF WG, etc.

PROPOSAL: In the HTML+RDFa spec, de-percent encode values retrieved from @href and @src in HTML5 before generating a triple based on those values. Include a warning that this feature is at risk during the Last Call.

gkellogg: I'm concerned about inter-operability... my library will not translate from IRI to URI... this concerns JavaScript implementations... anything using an infoset will get different results.
... We should note that that is a potential issue.

ShaneM: I appreciate what you're talking about wrt. percent-decoding - but what about URIs that have percents in them, happens all the time.

gkellogg: HTML5 spec is pretty specific, it has different rules for scheme, query, host portions - it's not simple.

niklasl: Section 3.2 in the IRI spec might provide a means to lift items from URI to IRIs in a predictable manner. We may want to look at that more. If you do this in an HTML+RDFa parser, you have to check to make sure the input is UTF-8 decoded as well.

manu1: Do we want to implement this across everything that could contain an IRI?

ShaneM: absolutely.

manu1: If we do a percent-decoding across @href, @src, @about, @resource - will we get back what HTML5 expects as well?

gkellogg: I think so, yes.
... For consistency's sake - it might be strange if you had @about not do percent-decoding, but did have percent-decoding in @href.

ShaneM: String comparisons wouldn't match between @about and @href, even if you dereference it, it refers to the same resource.

<ShaneM> For instance if url was "//example.com/a^b☺c%FFd%z/?e", then the <path> component's substring would be "/a^b☺c%FFd%z/" and the two characters that would have to be escaped would be "^" and "☺". The result after this step was applied would therefore be that url now had the value "//example.com/a%5Eb%E2%98%BAc%FFd%z/?e".

MacTed: That's a bug in the HTML5 spec.
... It's presuming that the input wasn't percent-encoded.

<ShaneM> so we would transform http://www.example.com/foobar%2cblat to http://www.example.com/foobar,blat right?

manu1: Shane, yes - that is what the output should be.

<niklasl> <http://example.org/å> = <http://example.org/%C3%A5>

niklasl: I tried out the example above for both values, I get different IRIs internally from it.
... So, that's an argument against.

<ShaneM> can we just defer to the RDF working group on this?

gkellogg: I don't think we want to make a spec change at this point.
... I don't think anyone from the HTML WG have responded on this particular issue to Jeni's bug report on the problem. Issues should be raised on this in the HTML WG.
... We should put a note in the HTML+RDFa spec notifying authors that this is the behavior for IRIs in @href, @src and @data.

PROPOSAL: Place a note in the HTML+RDFa specification notifying authors that IRIs placed into @href, @src and @data could be transformed if access via the DOM

<gkellogg> +1

+1

<niklasl> +1

<ShaneM> +1

<MacTed> +1

RESOLUTION: Place a note in the HTML+RDFa specification notifying authors that IRIs placed into @href, @src and @data could be transformed if access via the DOM.

ISSUE-117: Do not automatically define @about on <body> and <head>

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

ShaneM: We do specify a default @about on the HTML element already - current subject is set to <base>
... The implicit ones on HEAD and BODY is so that you could have a @typeof on the HEAD and BODY and have it refer to the document.

<ShaneM> toby said: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0106.html

gkellogg: How common is it to have @typeof on HEAD and BODY without an @about or a @resource?

manu1: This issue isn't causing any damage right now, it also doesn't implement any new use cases.

<ShaneM> mark makes a good argument here: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0151.html

niklasl: One possible issue is examples of this gives the impression that @typeof doesn't create bnodes.

<niklasl> … <html about="/b"><h1 property="dc:title">B?</h1>

<ShaneM> ... <html about="/b"><head typeof="foaf:Document"> ...

gkellogg: This is an issue - how do you deal with documents that are malformed being processed via an XML-based processor that are HTML5 documents?

<MacTed> inheritance preservation does feel like the right way to express this

ShaneM: I agree with Gregg - in the example above, we don't want to change the @subject for our author.

<niklasl> <body about="">

<niklasl> … <html about="/b"><body about=""><h1 property="dc:title">B?</h1>

niklasl: I agree - @property is applied to whatever the current subject is in the current rules... for @typeof

<ShaneM> Original text: In section 7.5, processing step 5, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if there is an empty @about present, and process it according to the rule for @about.

<ShaneM> Revised text: In section 7.5, processing step 5, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if new subject is set to parent object.

<ShaneM> and: In section 7.5, processing step 6, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then act as if new subject is set to parent object.

<ShaneM> I note that this has a (very minor) backward compatibility concern

PROPOSAL: Modify HTML+RDFa and XHTML+RDFa to modify processing steps #5 and #6 from assuming an empty @about value to assuming that new subject is set to the parent object.

<gkellogg> +1

+1

<MacTed> +1

<ShaneM> +1

<niklasl> +0.5

RESOLUTION: Modify HTML+RDFa and XHTML+RDFa to modify processing steps #5 and #6 from assuming an empty @about value to assuming that new subject is set to the parent object.

ISSUE-122: @datatypeLibrary attribute

https://www.w3.org/2010/02/rdfa/track/issues/122

manu1: Anyone in support of this proposal?

<niklasl> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0030.html

<gkellogg> From ivan: I am not convinced that the use cases warrant an additional level of complication in the RDFa definition. I would prefer not to take this.

manu1: I agree with that sentiment.

niklasl: I agree - we pre-define xsd as a prefix, no need for this.

<ShaneM> ack

manu1: I see no compelling use cases for this.

PROPOSAL: Do not support @datatypeLibrary proposal due to lack of compelling use cases.

+1

<niklasl> +1

Ivan: +1

<gkellogg> +1

<ShaneM> +1

RESOLUTION: Do not support @datatypeLibrary proposal due to lack of compelling use cases.

ISSUE-121: Use @id to set the subject in RDFa

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

manu1: The issue with this suggestion is that we tread very heavily into HTTPRange-14 issues...

gkellogg: No compelling use case for it - very dangerous because it would break many documents that already use @id.
... HTTPRange-14 is a huge issue as well... @id is in a different namespace as @about - I'm against including this feature in RDFa processing.

<niklasl> … <div id="p_1" property="paragraf" resource="#p_1" typeof="Paragraf">

niklasl: I'm against it as well... it's always been something I would've liked, my primary use case for RDFa is for legal information, where we refer to document fragments more often than not.
... I have to use @resource on the same DIV... however, I'm still against doing what is proposed... very tricky to get what Sebastian is proposing right.
... Too complicated, don't support it.

<Zakim> just, you wanted to mention the role attribute

ShaneM: I think it's a bad idea - @role attribute spec uses the value of @id as the subject... but you need both.

PROPOSAL: The @id attribute MUST NOT be used to identify a subject in RDFa.

<gkellogg> +1

+1

+1 (from Ivan)

<niklasl> +0.95

<ShaneM> +1

RESOLUTION: The @id attribute MUST NOT be used to identify a subject in RDFa.

<niklasl> (.. the 0.05 is for my dream of a good working solution ;)

ISSUE-123: HTML Literals

https://www.w3.org/2010/02/rdfa/track/issues/123

gkellogg: The RDF WG has been looking at an HTML Literal - recent discussion on changes to XMLLiteral
... My issue with XML Literals have always been the canonicalization rules - they're not valid to use in HTML.
... Ivan's issue is that he doesn't know how an HTML Literal vs. an XML Literal would look...
... The purpose of XMLLiteral support in RDFa is to capture markup, and not to look for document equivalence, then I think something like an HTML LIteral or relaxed requirements for canonicalization is more in keeping with RDFa usage patterns.

manu1: I wonder if there is any solution that we could create that would work both in XML-based and HTML-based parsers... I don't think there is.

gkellogg: Maybe the value should be the Infoset?
... Exclusive canonicalization does more in terms of namespaces.... we may not want to do that sort of processing. wrt. an HTML document - there can be no namespaces... the effect may be equivalent. To say we coerce to Infoset, we are allowing the HTML parser to normalize the tagsoup and get a valid XHTML type representation of that content.

niklasl: I think what we might be after is a way, given that we're in HTML, to use an equivalent to XHTML parsers - by using innerHTML property. I think that's spec'ed out in HTML5 spec.

gkellogg: If we just use innerHTML, the lexical representation is potentially tag soup. Presumably the value is an infoset.

niklasl: Looking at the issue, this should be an HTML+RDFa issue... doesn't apply to RDFa Core - maybe we should wait for RDF WG to work through this issue.

Publication of RDFa Core 1.1

PROPOSAL: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011.

<gkellogg> +1

+1

<niklasl> +1

We will also get +1s from the RDF Web Apps WG mailing list.

<ShaneM> +1

RESOLUTION: Publish an updated Working Draft of RDFa Core 1.1 on December 15th 2011.

Publication of XHTML+RDFa 1.1

PROPOSAL: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011.

+1

<niklasl> +1

<gkellogg> +1

<ShaneM> +1

We will also get +1s from the RDF Web Apps WG mailing list.

RESOLUTION: Publish an updated Working Draft of XHTML+RDFa 1.1 on December 15th 2011.

trackbot, make logs public

<trackbot> Sorry, manu1, I don't understand 'trackbot, make logs public'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

<MacTed> trackbot, end meeting

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: manu1
Inferring ScribeNick: manu1
Default Present: manu1, MacTed, niklasl, gkellogg, ShaneM
Present: manu1 MacTed niklasl gkellogg ShaneM
Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Dec/0025.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 08 Dec 2011
Guessing minutes URL: http://www.w3.org/2011/12/08-rdfa-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.