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

[John Arwe]

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

It's a requirement IFF the (only?  primary?) intended use of the data is 
to push it through an HTML rendering engine.  Which is a fine use, but 
certainly not the only one, certainly not what the existing spec says 
"...may be used in the display of a link...".  If I push the value into a 
log instead/in addition to your intended use, less clear what the value 
is/should be.  Once you tell me it's a string, I don't think I'm entitled 
to assume (in a "follow your nose" sense) anything about its internal 
format.  By virtue of its occurrence inside a message payload with 
Content-Type: application/xml (or ... +xml), I am entitled/required to 
assume that its value has been XML-escaped *because of the media type 
specification's warrants*.

Your revised draft leaves the "only content valid w/in <span>" HTML 
constraint a SHOULD; MUSTing HTML escaping seems even more bizarre in the 
context of ("under") a SHOULD.  If your intent is "When the content 
contains content that is intended to be interpreted as HTML markup, then 
it MUST...", I'd be comfortable with that in terms of its effect on 
providers; that's not what the draft says today however.  Clients I think 
are no better/worse off, strictly from a spec perspective, and better off 
from an expectations-setting perspective.

If the order of XML/HTML escaping applies matters (alternative orders 
yield distinct final outputs on the wire) then we'd also need to specify 
escaping order.  Presumably a serializer would HTML-escape the value 
first, and then XML-escape the entire representation next; a deserializer 
would have to reverse that process.


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

Adding a MUST is incompatible; reducing that MUST's scope of applicability 
does help limit the effects.  If incompatible change is the price of 
fixing something that's just totally broken as it exists today, I can get 
over it.  Likewise if every reader interprets the spec differently (that's 
just another form of totally broken).


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/20120709/bbdce8e4/attachment-0003.html>