[oslc-core] Proposal for Issue-25: Encoding of UI preview label

[Steve K Speicher]

Comments added below and new draft attached 

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 06/27/2012 02:07 PM
> Subject: Re: [oslc-core] Proposal for Issue-25: Encoding of UI preview 
label
> Sent by: oslc-core-bounces at open-services.net
> 
> The revised text is cut off on the right (description) in the PDF. 
> 
Hopefully the new attached draft fixes this.

> From what I can see in the draft: 
> dcterms:title as string instead of XML literal seems consistent with its 

> Dublin Core definition [1] which says range=rdf:Literal 
Yes

> Provider’s should not be possessive (lose the apostrophe). 
> 
Fixed

> Not clear why we're saying that it MUST be HTML-escaped ... that would 
imply
> that the string is in fact always (X)HTML.  Certainly true that its 
value 
> would have to be XML-escaped as part of serializing it into a 
well-formed 
> XML document (I'm not sure of the relationship between HTML-escaping and 

> XML-escaping to the required level of precision, is one a proper subset 
of 
> the other?). 
I believe it is a requirement.  If we are expecting that web browsers may 
(after proxying the request and sanity checking for potential security 
issues) just place the string content of the <dcterms:title> within an 
html element, maybe <span>, for easy rendering.  By doings this, it will 
keep things consistent (we did go through a review with a number of 
implementations in what they are doing).

> oslc:shortTitle as string instead of XML literal seems consistent with 
> dcterms:title, which seems to be important given its description [2]. 
> 
> 
> Both value type changes might be seen as incompatible by some observers. 
 Do
> we have reason to think that this change is either compatible upon 
closer 
> inspection, or it's worth the pain (potential breakage) in existing 
> implementations?  Just asking in the hopes that analysis has been 
done... I 
> know from personal experience that sometimes the obvious turns out to be 

> false upon deeper thinking. 

Reminder, we are talking about XML elements here and NOT RDF vocabulary 
terms.  So what we define within this UI Preview spec and oslc:Compat is 
limited to the usage of those XML elements as child elements of 
oslc:Compact.  If there are changes to the core/common vocabulary that 
will be a separate issue to consider.  Just want to be clear.

> [1] http://dublincore.org/documents/dcmi-terms/#terms-title 
> [2] http://open-services.net/bin/view/Main/OslcCoreVocabulary#shortTitle 

> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 
> 
> 
> From:        Steve K Speicher/Raleigh/IBM at IBMUS 
> To:        oslc-core at open-services.net 
> Date:        06/27/2012 09:47 AM 
> Subject:        [oslc-core] Proposal for Issue-25: Encoding of UI 
preview label 
> Sent by:        oslc-core-bounces at open-services.net 
> 
> 
> 
> See attached proposal writeup.  I am intentionally trying to provide a 
> minimal fix and not open another can of worms. 
> 
> I will proceed with making this change unless I hear any objections on 
call 
> today or via email by July 5. 
> 
> [1] - http://open-services.net/bin/view/Main/OslcCoreV2Issues #25 
> 
> Thanks,
> Steve Speicher | IBM Rational Software | (919) 254-0645 
> 
> [attachment "Issue-25 Proposal.pdf" deleted by John 
Arwe/Poughkeepsie/IBM] 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120627/31b8b5ab/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Issue-25 Proposal.pdf
Type: application/octet-stream
Size: 126348 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120627/31b8b5ab/attachment.pdf>