Re: New Draft comments: textual bodies

>
>     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 metadata.
> Unless literals are restricted to *only* text/plain. So no markup at all.


Hey, you've cut my comment in the middle of the paragraph ;-)
I was indeed not recommending that everything becomes metadata-free literals...


>
>     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.


A bit surprising, but well, that's enough to answer my worries.


>     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.



Remember, I had proposed to explore SKOS-XL like pattern, where the semantics state rule to convert from one pattern to the other. Which in turn allows all kinds of nice stuff, like still handling cardinality constraints in an appropriate way. You did not react to this option...
Anyway, the consequences for multiplicity remain to be checked. You could be fully right. I'll try to have a look when reviewing that part of the draft.

Note again that I'm not against people with more complex requirements (multiplicity) having to use more complex patterns. I'm just for allowing the simple pattern for these with simple needs.

Cheers,

Antoine

Received on Friday, 11 January 2013 07:49:35 UTC