RDF-in-XHTML Task Force

Action Review

ACTION: [PENDING] Ben to put up information on "how to write RDFa" with screencast possibly and instructions on bookmarklet. [recorded in http://www.w3.org/2008/11/06-rdfa-minutes.html#action12]

ACTION: [PENDING] Jeremy to demonstrate GRDDL with XHTML/RDFa once the NS URI is set up. [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action03]

ACTION: [DONE] Manu to look at http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Dec/0037.html about resolving relative URIs [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action15]

Manu: I've replied and asked twice for a response
... I think they're accepting the response
... so I think we can consider this done

ACTION: [PENDING] Manu to write summary for Semantic Web Use Cases for Ivan. [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action09]

ACTION: [PENDING] Mark create base wizard suitable for cloning [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action12]

ACTION: [DONE] Mark to review reasoning on setting explicit about="" on HEAD and BODY [recorded in http://www.w3.org/2008/12/18-rdfa-irc]

-> The implied @about="": Explanation and some problems [Mark 2009-04-01]

ACTION: [PENDING] Mark to send Ben ubiquity related wizard stuff [recorded in http://www.w3.org/2008/11/20-rdfa-minutes.html#action11]

ACTION: [PENDING] Mark write foaf examples for wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action13]

ACTION: [PENDING] Michael to create 'RDFa for uF users' on RDFa Wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action14]

ACTION: [PENDING] Ralph or Steven fix the .htaccess for the XHTML namespace [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action01]

Ralph: I know Steven poked someone about this

ACTION: [PENDING] Ralph think about RSS+RDFa [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action15]

Report on AC Meeting

Manu: anyone there for the HTML discussions than Ben and Steven?

Shane: unfortunately Ben couldn't stay for the breakout session

Mark: the minutes suggest the discussion was quite positive

Ralph: I needed to participate in a different breakout

Mark: I'm looking at the minutes of the Backplane XG

Shane: there appears to be substantial support from the Membership for the extensibility model that XHTML has always had

@prefix syntax discussion

Manu: at our last discussion, Shane and Ralph were favoring the '=' syntax and Mark and I were favoring the JSON-esque syntax
... any new thoughts in the subsequent 2 weeks?

Mark: I'm involved in a couple of projects where folk are producing what they think is RDFa
... it's interesting; I see a growing need for tools to check the work
... simply typos like mismatch between namespace declaration and usage

Ralph: no real additional thoughts but I did make note of Mark's concerns about the pattern @attr="prefix=value"
... but if tools are generating this anyway, how much does it matter?

Mark: I'm thinking of checking tools more than generation tools

Manu: definitely think embedded '=' will cause confusion
... and people will put whitespace around the '='
... so we need resilient syntaxes and parsers

Shane: I don't think it's terribly important to have delimiters other than whitespace between the items
... but I won't fight on that
... I understand the sensitivity to the repeated '=' issue
... do you prefer ':'?

Manu: yes

Shane: that's probably fine, but then you end up with repeated ':'

<ShaneM> perfix="xhv:http:..."

Shane: I leaned toward repeated '=' in the first place because that made it clear which was the prefix and which was the rest

<markbirbeck> prefix="xhv:xyz dc:xyz"

<markbirbeck> prefix="xhv=xyz dc=xyz"

Mark: we're tending to discuss as if [the two examples above] were the patterns
... this is how @xml:schemalocation works

<markbirbeck> prefix="

<markbirbeck> xhv: xyz,

<markbirbeck> dc: xyz

<markbirbeck> "

Mark: I'm thinking we should really be looking at layout such as [above in irc]
... in this case, additional delimiters are useful; we don't need to be compact
... we should consider not just a syntax but also examples that people will cut & paste
... if I were to copy one of Manu's audio prefix examples I could select a single line (of many declarations) and insert it into my list without introducing error
... once you spread things out like this, why not allow further flexibility

<markbirbeck> prefix="

<markbirbeck> 'xhv': 'xy z',

<markbirbeck> dc: xyz

<markbirbeck> "

Shane: my concern is that URIs allow these characters, so the syntax rules and the parsing are both more challenging

Mark: yes, but there are extra options for delimiting
... if we say we're allowing quotes _as well_ this gives additional flexibility

<markbirbeck> prefix="

<markbirbeck> 'xhv': 'xy z,',

<markbirbeck> dc: xyz

<markbirbeck> "

Mark: if you did have a URI that ends in ',' then quoting allows an easy way to include it
... ':' in @xmlns was really an effort to find one thing that would work
... but we have greater flexibility

Manu: when people mint prefix mapping URIs I find it highly unlikely that they'll use a ',' in such a URI
... yes, it _could_ happen but if it's a well-known design consideration that such characters cause trouble then vocabulary developers can avoid them

Mark: what is the added complexity?

Manu: it's additional complexity in the parser. I'm questioning whether we really need it.

Mark: it's one regular expression
... a way of trying to introduce resilience and something that [humans] can grok easily
... we come back to this problem of recognizing what is a URI
... I'm just thinking of ways to provide resilience when needed without mandating it all the time

<markbirbeck> prefix="

<markbirbeck> xhv: {xy z,},

<markbirbeck> dc: xyz

<markbirbeck> "

Manu: I'd like to see the regex
... my C+sax-based parser doesn't have to use regex's anywhere right now

Mark: a space-separated list needs to be cracked into a list
... even '=' can appear in a URI

<ShaneM> index

Manu: I don't think we can count on authors writing examples consistently
... and a mixture of styles will cause confusion

Mark: I'm proposing the _possibility_ of permitting this richer format, not _requiring_ it

Manu: I was only questioning whether example authors will really write the examples with multi-line declarations

<markbirbeck> prefix="xhv: xy, dc: xyz"

Manu: when the examples are written on a single line the richer syntax becomes confusing

Mark: consider space-separated lists

<markbirbeck> prefix="xhv:xy dc:xyz"

Mark: then you can't have space around ':'
... the options for authors laying out the markup are limited
... no flexibility for aligning things [in columns]
... whereas the XML attribute syntax has a lot of flexibility, for example; can use whitespace to nudge things [into columns]
... in terms of consistency, generally in XML spaces are ignored
... other than the use in XML Schema to create lists, whitespace is not significant

Shane: whitespace is collapsed, not ignored
... this includes newlines
... collapsing inside attributes values
... however, this is bad; in the HTML DOM whitespace is not collapsed
... this means a parser that has to work with both XML and HTML has to be written to expect multiple whitespace

Mark: but the presence of whitespace is geenerally not significant
... as long as there is whitespace in key places, such as between attributes
... '=' vs. ':' is a separate discussion from whether whitespace is a delimiter

Manu: I agree; we shouldn't decide solely on whitespace

<msporny> prefix="xhv:xy, dc:xyz" prefix="xhv:xy; dc:xyz"

Manu: for delimiters between mappings, we're considering something like ^

Shane: a lot of our canonical examples are ones that contain ','; e.g. Wikipedia or Amazon
... places where, for example, an ISBN might be interpolated

<msporny> prefix="media: http://purl.org/media#, audio: http://purl.org/media/audio#"

Mark: yeah, can't quickly come up with an example

<markbirbeck> mapping, mapping, mapping

Mark: should treat as mapping, mapping, mapping
... then decide what goes inside mapping

<msporny> prefix="media: http://purl.org/media# ; audio : http://purl.org/media/audio#"

Shane: can't just be 'ends in comma' -- must be 'includes comma'

Manu: are Shane and Ralph ok with using ',' between mappings?

Shane: if we're going to use ',' or ';' we need to define the escaping mechanism
... maybe there's already a mechanism defined somewhere
... my preferred syntax is identical to schemalocation [i.e. alternation] but Ralph says that's a non-starter

Manu: ok to pick a character that must be URI-encoded in URIs?

<msporny> http://en.wikipedia.org/wiki/Percent-encoding

Mark: every time I look at the URI spec I find it allows more characters than I expected
... this discussion is pretty much the same discussion the @xmlns folk had to go through

Manu: we could require that reserved characters must be %-encoded
... but that makes everything harder

Mark: and we'd have to avoid a requirement to double-encode
... we need a non-reserved character

Shane: good luck with that!
... remember that in the case of CURIE it's a IRI
... so even a bigger set of non-reserved character
... the only reserved character is space
... even schemalocation cheated by not using '=' or ':'; they just use alternation
... the problem with alternation is that we can't do anything clever with default or absent prefixes
... but maybe we don't need such rules

<msporny> prefix="a=b x=y"

<ShaneM> wow.... we already have this problem!

Mark: if we needed @prefix on every element then perhaps we might go with [the '=' syntax]

<ShaneM> xmlns:foo="URI" what happens if URI contains a quotation mark?

Mark: but perhaps we don't need that flexibility; be more restrictive
... put everything in the head or having a predicate indicating a prefix mapping

Ralhp: predicate as in RDF predicate?

Mark: yes

<ShaneM> <meta rel="prefix" name="foo" resource="URI" />

Mark: however I didn't like that syntax as it puts meta information in the same graph as 'ordinary' information, which feels wrong
... I'm looking for something that is "cut-and-paste reliable"

Ralph: Creative Commons would not accept restrictions on where mappings can be declared

Shane: separate two issues; 1. can we provide an alternative to @xmlns that would be acceptable beyond the XML community and 2. how do we make it easier for our constituents to use RDFa in easier ways
... we've talked about having external documents that declare prefixes
... perhaps even with some well-known prefix declarations
... maybe we'll make more progress by not trying to find a single solution to these two objectives

Mark: so do we need a lot of flexibility?
... find just enough flexibility for the goals at hand

<ShaneM> We should try hard to NOT over-engineer this solution without having the requirements in mind!

Manu: the second idea is that there's an @profile value that pulls in external mapping declarations

Mark: 1 is the namespace thing and 2 is ease of authoring

Shane: consider CSS syntax as an example of going too far; e.g. borders on table cells -- totally different behavior depending on how many values are supplied

<markbirbeck> dc: url(xyz)

Mark: I've just thought of another syntax!

Ralph: and it may be that the @xmlns problem will go away

<markbirbeck> Continuing Shane's point, why not 'solve' this:

<markbirbeck> http://wiki.creativecommons.org/CcREL

Mark: pick an example of something people will frequently want to copy and paste; e.g. ccRel
... the simple example [in ccRel] is interesting
... it just says some other mechanism has defined the token
... consider the lengthier scenarios; what other ways are there to address these?

Manu: any of our proposed syntaxes would handle these examples fairly cleanly

<msporny> prefix="a = b x = y"

Ralph: yeah, it's the ugly corner cases like ',' in URIs that are a problem

<msporny> prefix="a=b x=y"

Shane: even quote is already an issue

Manu: a simple state machine will handle the '=' syntax

<ShaneM> prefix="

<ShaneM> a = b

<ShaneM> x = y

<ShaneM> "

Manu: I see the argument for an extensible syntax that could support every use case but I wonder if [that flexiblity] will ever be used
... we're trying to solve a very simple problem

Shane: Mark's desire to make this legible can easily be written using the '=' syntax

<markbirbeck> Shane don't we do this: xmlns:a="&quot;b&quot;"

Shane: we can easily deal with extra whitespace

<markbirbeck> a = http://example.org?a=b

<ShaneM> (.*)\s*=\s*(.*?)\s+

<markbirbeck> prefix="a = http://example.org?a=b&c=d"

Manu: I'm leaning toward preferring this solution
... straightforward and easy to implement

<ShaneM> actually - can't use \s... need [\s\r\n]

Manu: don't think there's much danger of authors confusing the syntax in the markup

next meeting: 2 weeks (April 16)

[adjourned]

<ShaneM> (.*)[\s\r\n]*=[\s\r\n]*(.*?)[\s\r\n]+