W3C home > Mailing lists > Public > public-openannotation@w3.org > January 2013

Re: New Draft comments: textual bodies

From: Robert Sanderson <azaroth42@gmail.com>
Date: Thu, 10 Jan 2013 16:22:00 -0700
Message-ID: <CABevsUFTWC-f0RLMFHw93qg9VfeXNMfJ33Ke-9B=DWyRxFR8DA@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation@w3.org
On Thu, Jan 10, 2013 at 3:01 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> What Rob suggests goes clearly in the right direction.

> Yet  again I have problems with some of the argumentation.
> But "The typing and assignment of a MIME type to the text string
> (especially text/plain vs text/html) is very important for clients" does
> not convince me.

Then there's Markdown, various wiki languages, RTF, various XML or JSON
dialects for mark up, etc etc.  I don't see a client could be expected to
know even that it can't properly render a comment without some level of

Unless literals are restricted to *only* text/plain. So no markup at all.

One could easily default to process plain literals as text/plain.

True, and it would look hideous if it wasn't actually text/plain.  We don't
want to encourage the broken windows of previous systems.  Similarly you
could display ContentAsBase64 as text/plain ... but it wouldn't do much
good to anyone.

> And quite sneakily this raises the question of typed literals. Has nobody
> ever asked for using XML datatypes directly instead of resources that may
> be only awkwardly mapped to these datatypes?

It was raised as a question once, I believe by Tim Cole, but no one had a
use case for it.

To draw this to a close:
>> * We will adopt the blank node with a single cnt:chars property method
>> for when identity is considered unnecessary.
>> * The rationale given in the document will be updated to include typing
>> (as below), OWL-DL and integration, and to downplay the bullets that
>> Antoine mentioned as less convincing in his original email.
>> * The dctypes:Text additional class will be a MAY rather than a SHOULD
>> * The assignment of cnt:ContentAsText will be a SHOULD rather than a
>> MUST, as this is easily able to be inferred from the presence of cnt:chars.
>> Note that cnt:ContentAsBase64 uses cnt:bytes, so the two are
>> distinguishable.
Further, literals are incompatible with the multiplicity constructs.  So
you couldn't have a Composite with two literals, or a literal and a
resource, without also making all of that part of the system this fuzzy
maybe-a-literal-maybe-a-resource property.

Received on Thursday, 10 January 2013 23:22:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:21 UTC