[oslc-core] XHTML vs simple text in OSLC Core's common properties

[John Arwe]

A subset of common properties has value-type = XMLLiteral and a 
description that says the content [should] include valid 
XHTML-within-<div> [1]; description and title are examples.
Most of Tivoli's existing product set expects "just straight strings" (no 
rich text/XHTML permitted; markup would be treated as strings, i.e. not 
recognized as markup).  I'm trying to avoid re-inventing new while still 
enabling existing products that would not, as servers processing a 
POST(Create)/PUT/PATCH, tolerate XHTML coming in.  I see oslc:name (within 
Resource Shapes) which is potentially re-usable (RS is part of Common as a 
resource definition, but oslc:name is not listed in common properties).
I would be interested in thoughts from Core on how best to accomplish the 
goal of enabling apps not yet ready to change to accept XHTML as described 
above. 
(1) One possibility would be to define a Common Property whose value is 
simply "String"; one might re-use oslc:name for that purpose (to avoid 
defining new) or simply define new. 
(2) I wonder out loud about an alternative of using the existing common 
properties with an explicit type of ^^String on the [RDF/XML at least... 
:-( want JSON too though] serialized representations.  But I find that not 
so appealing, since (at a bare minimum) it imposes requirements on client 
implementations to use serialization rules more restrictive than those 
defined in Core in order for one of my servers to accept the data.
(3) Becoming even more of a language lawyer than usual and noting that the 
existing descriptions of the relevant properties use a conditional 
(SHOULD), and the domain specs (like CM 2.0) only impose normative 
requirements on implementations (not representations).  So compliant 
service providers (should? must? not clear!) tolerate sans-XHTML values 
(good for me), and compliant clients (should, by my reading) provide 
with-XHTML values which my providers (may? should? must? not clear!) 
accept... I choose the "should" reading, but do not implement that, so my 
provider is compliant but less useful than ones that would accept 
with-XHTML values.  The reason I assert "not clear!" is: specs like CM 2.0 
[2] based on Core say "OSLC CM consumers and service providers MUST be 
compliant with both the core specification and this CM specification, and 
SHOULD follow all the guidelines and recommendations in both these 
specifications. "  I.e. they talk about compliance only in terms of 
consumers and providers, not resources.  In a case like [1]'s 
oslc:shortTitle, whose entire description is "Shorter form of 
dcterms:title for the resource represented as rich text in XHTML content. 
SHOULD include only content that is valid inside an XHTML <div> element. 
", it is left to the reader to decide the effects of the SHOULD.  There is 
no clear statement of responsibilities for service providers or consumers. 
 While my reading would be that compliant service providers MUST tolerate 
sans-XHTML values (good for me), compliant clients should provide 
with-XHTML values, and compliant service providers MUST accept with-XHTML 
values, if my evil twin read the last MUST as a SHOULD and challenged me 
to show which normative statement was violated then I would be hard 
pressed to find one.  If I change my goal to practical interop rather than 
trying to minimize the cost of shoe-horning my existing implementation 
within the letter of the spec, I have a reasonable case to argue for MUST. 
 [Aside and fair disclosure: [1] does in at least one place appear to 
attempt to place normative restrictions on a resource - foaf:person.  But 
I find no place in Core that defines compliance, so we revert to domain 
specs like CM 2.0 and the identical problem.]
(4) Clarify the meaning of "... SHOULD include only content that is valid 
inside an XHTML <div> element. " with respect to implementations, and then 
see where I stand.  The preceding seems ample evidence that the current 
text is ambiguous.
(5) Define an extension property(ies) that lack the XHTML restriction and 
use those until my implementations learn to recognize it as markup when 
present.  Which, in the case of a CM 2.0 ChangeRequest, means that it 
would be a gating factor in becoming compliant (dcterms:title = 1:1) as a 
service provider.
(6) Accept the with-XHTML values but do not render them in my UI.  Seems 
within my power at least, although not perfect.  The horse/water meme :-)

One could draw the conclusion OSLC assumes a Web-based UI when it requires 
these XHTML-enabled fields.  Is that an explicit intent of OSLC?  If it is 
UNintentional, 1:1 on XHTML-enabled strings would appear to be an 
anti-pattern.  Requiring a value and encouraging that value to contain 
XHTML but then saying "well you don't have to display them ever" seems 
incoherent - if they're not for display, why XHTML?

[1] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;table=up#OSLC_Properties
[2] 
http://open-services.net/bin/view/Main/CmSpecificationV2?sortcol=table;table=up#Compliance

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111115/06cfb7d2/attachment-0003.html>