From spadgett at us.ibm.com  Sun Aug  7 13:00:51 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Sun, 7 Aug 2011 13:00:51 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
Message-ID: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>


I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact
[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



From spadgett at us.ibm.com  Sun Aug  7 13:06:11 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Sun, 7 Aug 2011 13:06:11 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
Message-ID: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@us.ibm.com>


Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact
[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



From hudsonr at us.ibm.com  Mon Aug  8 11:41:54 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Mon, 8 Aug 2011 11:41:54 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
Message-ID: <OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>

Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett/Durham/IBM                                                                                                                         |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net <oslc-core at open-services.net>                                                                                         |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA                                                                                     |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:06 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSLC Compact representation, titles with markup                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact
[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



From johnarwe at us.ibm.com  Fri Aug 12 07:42:41 2011
From: johnarwe at us.ibm.com (John Arwe)
Date: Fri, 12 Aug 2011 07:42:41 -0400
Subject: [oslc-core] JSON representation rules - typo
Message-ID: <OFC62D3251.D54117F2-ON852578EA.004000CA-852578EA.00405726@us.ibm.com>

http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_JSON 
says, in part:

1.0 For each property of a resource 
1.1 Add field to the resource's JSON object with name set to Prefixed Name 
of property 
1.1.1 If the property is specified as a single-valued property, then make 
field's value literal or JSON Object 
1.1.2 If the property is specified as a multi-valued property, then make 
field's value JSON Array 
1.2 Else if value-type is Literal 
1.2.1 Set field's value to string representation of property value 

Note the "Else if" at 1.2 without a matching "If".  Odds are it should 
read "1.2 If value-type", i.e. just remove the initial Else.


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/20110812/a0b504ca/attachment.html>

From johnarwe at us.ibm.com  Fri Aug 12 09:47:31 2011
From: johnarwe at us.ibm.com (John Arwe)
Date: Fri, 12 Aug 2011 09:47:31 -0400
Subject: [oslc-core] Core 2.0 JSON Representation Guidelines - ambiguity in
 serialization of literals
Message-ID: <OF9958F3AB.828C0E72-ON852578EA.0045748F-852578EA.004BC51F@us.ibm.com>

At [1], under the rules to serialize each property, the prescription for 
Literal is to set the field's value equal to the "string representation" 
of the property value (pasted excerpt below, after [1]).  People are 
asking me if this means (for a value like 1.0 say in a property whose 
value-type is float), if that means 1.0 or "1.0".  Their interpretation of 
[1] is that "1.0" is the required output, implying that its JSON-type must 
be string; if the quotes were omitted, its JSON-type would be number, as I 
read [7].
In looking at the related examples and information about existing 
implementations (various flavors of "follow your nose" through the specs), 
I cannot answer this unambiguously using only the specs I have examined. 
Implementation samples suggest that the quotes are not required.  Here is 
a log of my travels; details for each are below.
[2] OSLC Core Specification:JSON Representation Examples appears to show 
only string and dateTime literals.  Since JSON does not have a native 
dateTime type, that document appears to be silent on this question. 
Recommendation: across the examples, cover each of the value-type 
possibilities.
[3] Open Services for Lifecycle Collaboration Core Specification Version 
2.0 Appendix A: Common Properties ; oslc:ResourceShape Resource lists 
(after the table) the valid value-type values, which includes 
integer/double and friends.  But no examples (they're in [2] in theory, 
fair enough if that were true).  Hmm.
[4] Wander over to CM examples; change requests at least have some 
booleans and dates, let's see how those are serialized in JSON as an 
indicator at least.  No such example.
[5] Remembering that CM defines a shape, and from [3] that shapes can have 
an integer maxsize and a boolean or two, try looking at the CM Shape. Only 
shown as an XML serialization :-(
[6] Having recently found out about the existence of a really good 
jazz.net article on RTC 3's CM usage, comb through that looking for what 
it tells me.  While this is not a guarantee of the spec's intent, it at 
least tells me what one implementation does, and since this implementation 
was one of those involved in spec convergence, it's a better-than-random, 
if not deterministic, example.  Pay-dirt at last, in Example 6 where it 
shows the serialization of oslc:responseInfo that includes 
"oslc:totalCount": 7, ...i.e., no quotes.
[6] Reading down further, I see "dc:identifier": 73, in Appendix B.  I'm 
"sure" identifier is a string, so why not "73"?  Checking in [3], indeed 
the value type of identifier is "string".  Now I'm really confused, or 
there is a bug in the article and/or the implementation from which the 
article was sourced.
[6] Futher down in Appendix B,  "rtc_cm:archived": false, which is 
consistent with totalCount (if the underlying intent is to use the JSON 
built-in types to the degree they match the value-type) but not with 
identifier.
[6] Yet further down, I find    "rtc_cm:correctedEstimate": null,   ... 
suggesting there may be yet another ambiguity in the serialization rules. 
I'm not sure what rule gets me to null, if all properties in RDF are 
optional.
Wander over to the QM spec [8] and its examples [9] + shapes [10].  Mostly 
strings, resources, and few dateTimes.  All the samples+shapes are XML.
Wander over to [11] Reqts Mgmt (since I thought that was implemented), but 
1.0 spec and wg page make me wonder.  Don't find any samples/shapes.
Am I missing something that explains why each of the examples above is 
either definitely right or definitely wrong, and similarly prescriptive 
information for all other value-types?



[1] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_JSON
These are the property rules referred to above. For each property: 
1.0 For each property of a resource 
1.1 Add field to the resource's JSON object with name set to Prefixed Name 
of property 
1.1.1 If the property is specified as a single-valued property, then make 
field's value literal or JSON Object 
1.1.2 If the property is specified as a multi-valued property, then make 
field's value JSON Array 
1.2 Else if value-type is Literal 
1.2.1 Set field's value to string representation of property value 
1.3 Else if value-type is Resource with representation of Reference
[2] http://open-services.net/bin/view/Main/OSLCCoreSpecJSONExamples
[3] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;table=up#oslc_ResourceShape_Resource
[4] http://open-services.net/bin/view/Main/CmSpecificationV2Samples
[5] http://open-services.net/bin/view/Main/CmSpecificationV2Shapes
[6] https://jazz.net/wiki/bin/view/Main/WorkItemAPIsForOSLCCM20
[7] http://tools.ietf.org/html/rfc4627
[8] http://open-services.net/bin/view/Main/QmSpecificationV2
[9] http://open-services.net/bin/view/Main/QmSpecificationV2Samples
[10] http://open-services.net/bin/view/Main/QmSpecificationV2Shapes
[11] http://open-services.net/bin/view/Main/RmHome

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/20110812/30fa7198/attachment.html>

From nally at us.ibm.com  Fri Aug 12 12:04:32 2011
From: nally at us.ibm.com (Martin Nally)
Date: Fri, 12 Aug 2011 10:04:32 -0600
Subject: [oslc-core] AUTO: Martin Nally/Raleigh/IBM is out of the office
 until 06/26/2000. (returning 08/22/2011)
Message-ID: <OF216EF641.205C8B2E-ON872578EA.00584E8E-872578EA.00584E8E@us.ibm.com>


I am out of the office until 08/22/2011.

For urgent CTO office issues, contact Michelle Swenson who will determine
the best option


Note: This is an automated response to your message  "Oslc-Core Digest, Vol
19, Issue 2" sent on 8/12/2011 10:00:10.

This is the only notification you will receive while this person is away.



From aggarwav at us.ibm.com  Fri Aug 12 16:15:10 2011
From: aggarwav at us.ibm.com (Vijay Aggarwal)
Date: Fri, 12 Aug 2011 16:15:10 -0400
Subject: [oslc-core] AUTO: Vijay Aggarwal/Austin/IBM is on vacation
	(returning 08/17/2011)
Message-ID: <OF369C28C8.BF60AFA7-ON852578EA.006F40A4-852578EA.006F40A5@us.ibm.com>


I am out of the office until 08/17/2011.

I will be on vacation until August 17.  Please contact Chris Doan for
Service Desk topics, Daniel Wiegand for Service Catalog topics and James
Matlock for WellPoint topics.  For customer engagements, please contact Bob
Dunyak.

Thanks.
Vijay


Note: This is an automated response to your message  "Oslc-Core Digest, Vol
19, Issue 2" sent on 08/12/2011 12:00:10.

This is the only notification you will receive while this person is away.



From sspeiche at us.ibm.com  Mon Aug 22 10:14:06 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Mon, 22 Aug 2011 10:14:06 -0400
Subject: [oslc-core] JSON representation rules - typo
In-Reply-To: <OFC62D3251.D54117F2-ON852578EA.004000CA-852578EA.00405726@us.ibm.com>
References: <OFC62D3251.D54117F2-ON852578EA.004000CA-852578EA.00405726@us.ibm.com>
Message-ID: <OF6FBE34F4.2C77D0ED-ON852578F4.004E2444-852578F4.004E31FA@us.ibm.com>

Thanks John, I made the fix

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

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 08/12/2011 09:24 AM
> Subject: [oslc-core] JSON representation rules - typo
> Sent by: oslc-core-bounces at open-services.net
> 
> 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?

> sortcol=table;up=#Guidelines_for_JSON says, in part: 
> 
> 1.0 For each property of a resource 
> 1.1 Add field to the resource's JSON object with name set to Prefixed 
Name 
> of property 
> 1.1.1 If the property is specified as a single-valued property, then 
make 
> field's value literal or JSON Object 
> 1.1.2 If the property is specified as a multi-valued property, then make 

> field's value JSON Array 
> 1.2 Else if value-type is Literal 
> 1.2.1 Set field's value to string representation of property value 
> Note the "Else if" at 1.2 without a matching "If".  Odds are it should 
read 
> "1.2 If value-type", i.e. just remove the initial Else. 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net



From ryman at ca.ibm.com  Mon Aug 22 16:10:19 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Mon, 22 Aug 2011 16:10:19 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@us.ibm.com>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@us.ibm.com>
Message-ID: <OFFB796645.6E9BAC4D-ON852578F4.006C9480-852578F4.006E7512@ca.ibm.com>

Sam,

You are correct. If you need to include formatting markup in text, the you 
should use the XML Literal datatype and put XHTML in it. XML Literal 
allows any well-formed  XML fragment, e.g. anything that is valid XML 
element content.

Your example is almost correct. It should also include the XHTML namespace 
declaration. A processor could assume that tags in the default namespace 
are XHTML. However, you should be explicit and include the namespace 
declaration:

  <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml ">12345: <s>Null pointer exception
during startup</s></dcterms:title>


A looked at the core spec [1] for dcterms:title and noticed another typo. 
The description description says:


Title of the resource represented as rich text in XHTML content. SHOULD 
include only content that is valid inside an XHTML <div> element. 

I think this was just copied from the description for dcterms:description, 
which SHOULD be like a <div>. A dcterms:title SHOULD be like a <span>, 
i.e.:

Title of the resource represented as rich text in XHTML content. SHOULD 
include only content that is valid inside an XHTML <span> element. 

[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:07 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From ryman at ca.ibm.com  Mon Aug 22 16:40:25 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Mon, 22 Aug 2011 16:40:25 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
Message-ID: <OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>

Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From ryman at ca.ibm.com  Mon Aug 22 16:55:36 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Mon, 22 Aug 2011 16:55:36 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
	<OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
Message-ID: <OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>

Randy,

I think example [3] is wrong. If the datatype is plain text then you 
should not assume it contains encoded HTML. If you need to include markup 
then you should use XML Literal datatype, and use XHTML content. This is 
described in the core spec [4] which gives guidance for putting markup in 
dcterms:title and dcterms:description.

[4] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Randy Hudson <hudsonr at us.ibm.com>
To:
Samuel Padgett <spadgett at us.ibm.com>, Steve K Speicher 
<sspeiche at us.ibm.com>
Cc:
Adam Archer/Toronto/IBM at IBMCA, "oslc-core at open-services.net" 
<oslc-core at open-services.net>
Date:
08/08/2011 11:54 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be 
wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett/Durham/IBM                              |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net <oslc-core at open-services.net>            |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA           
                   |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:06 PM                        |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSLC Compact representation, titles with markup         |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From agarcher at ca.ibm.com  Mon Aug 22 17:00:05 2011
From: agarcher at ca.ibm.com (Adam Archer)
Date: Mon, 22 Aug 2011 17:00:05 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
Message-ID: <OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>

The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at).

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From:   Arthur Ryman/Toronto/IBM
To:     Samuel Padgett <spadgett at us.ibm.com>
Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110822/2dae579d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110822/2dae579d/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110822/2dae579d/attachment-0003.gif>

From davidms at ca.ibm.com  Tue Aug 23 00:02:44 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Tue, 23 Aug 2011 00:02:44 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
Message-ID: <OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>


Hi all,

I've been following this thread with interest, as it touches on some of the
more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated as
a simple string or as HTML content. And that's the very thing that typed
literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type is
supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types in
both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than XMLLiteral
eliminates the "benefit" of the special rdf:parseType="Literal" syntax. And
without that, I don't see a particular benefit in the stricter XHTML
syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I believe
that, strictly, the XHTML namespace is required for the elements to be
valid XHTML. But I found no hint of this in the spec or any examples, and
certainly RTC doesn't do this (I haven't checked other providers).
Moreover, I believe it's also a worse approach, since there's no guarantee
that your RDF runtime of choice will give you access to namespaces declared
on the property element (I don't believe Jena does), and detecting a
namespace inside the element content would require actually parsing the
value as XML. If all you want to do is pass markup along for display in a
browser, it would be unfortunate to have to actually parse the content to
determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably just
as good as, if not better than, XHTML. Rather than worrying about whether
the content is well-formed XML, it's probably sufficient to just give it to
the browser and see what it can do with it. I would assert that "something
a browser can render" has been the working definition of HTML for a good
number of years now, while XHTML has largely faded in importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it via
OSLC. Likewise, a consumer may use a rich text control that yields HTML.
Generalized parsing of HTML for conversion to XHTML is non-trivial, and it
seems unfortunate to impose that conversion task onto everyone, just so
that we can use rdf:parseType="Literal" in RDF/XML and avoid applying
normal XML encoding to markup content (of course, some encoding will likely
be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if they
all do make perfect sense (and I'm not necessarily claiming they do), I
realize we may be well past the point of being able to act on them. Still,
I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property needed
to change. This is a related, but separate, topic, which I'd be thrilled to
discuss further, but I don't want to open too many cans of worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                             
  From:       Adam Archer/Toronto/IBM at IBMCA                                                                  
                                                                                                             
  To:         Arthur Ryman/Toronto/IBM at IBMCA                                                                 
                                                                                                             
  Cc:         "oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson                      
              <hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net                                      
                                                                                                             
  Date:       08/22/2011 06:20 PM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             
  Sent by:    oslc-core-bounces at open-services.net                                                            
                                                                                                             





The big concern to me is not the ability to process the RDF/XML with XPath,
it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply taking
the content of the attribute, decoding it (which browsers are very good at)
and slapping the result into the dom (which browsers are also very good
at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I don't
even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine what
the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From:        Arthur Ryman/Toronto/IBM
To:        Samuel Padgett <spadgett at us.ibm.com>
Cc:        Adam Archer/Toronto/IBM at IBMCA, Randy Hudson
<hudsonr at us.ibm.com>, "oslc-core at open-services.net"
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net
Date:        08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one point
we tried to define an OSLC-variant of RDF/XML that looked like "normal"
XML. However, we abandonned that and now require support for generic
RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an RDF
toolkit like Jena.

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                   Twitter | Facebook | YouTube   
                                                                                
                                                                                
                                                                                





                                                                           
 From:    Samuel Padgett <spadgett at us.ibm.com>                             
                                                                           
 To:      "oslc-core at open-services.net" <oslc-core at open-services.net>      
                                                                           
 Cc:      Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
                                                                           
                                                                           
 Date:    08/07/2011 01:01 PM                                              
                                                                           
 Subject: [oslc-core] OSLC Compact representation, titles with markup      
                                                                           
                                                                           
 Sent by: oslc-core-bounces at open-services.net                              
                                                                           
                                                                           







I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

 <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

 <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

 <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110823/42ed4e89/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19967617.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19394555.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0007.gif>

From sspeiche at us.ibm.com  Tue Aug 23 09:13:55 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 23 Aug 2011 09:13:55 -0400
Subject: [oslc-core] REMINDER: Core WG Meeting tomorrow (Wed Aug 24) 10:00 ET
Message-ID: <OFE7F482C2.46469320-ON852578F5.00472DA8-852578F5.0048AF8A@us.ibm.com>

Date: Wednesday, 24 August 2011
Time: 10:00 AM Eastern

Agenda:
 - General news
 - Time / date of meeting (some have hard conflict)
 - 2.0 spec issues
  - ui preview label encoding
  - json rep ambiguities
 - 3.0 themes, priorities and timeline development

http://open-services.net/bin/view/Main/OslcCoreMeetings

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



From ryman at ca.ibm.com  Tue Aug 23 10:10:06 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 23 Aug 2011 10:10:06 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
Message-ID: <OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DD584@ca.ibm.com>

Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 
datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 
parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 
preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 
However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 
since it impairs interoperability.

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

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/23/2011 12:06 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 
use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 
of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 
a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 
in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 
XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 
note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 
syntax. And without that, I don't see a particular benefit in the stricter 
XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 
consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 
"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 
I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do


From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From ryman at ca.ibm.com  Tue Aug 23 10:40:18 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 23 Aug 2011 10:40:18 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
Message-ID: <OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.00509995@ca.ibm.com>

Adam,

Your argument for escaping HTML is based purely on the use case of compact 
rendering. However, the OSLC specs are designed to enable many other use 
cases and to promote general interoperability among different tools.

The OSLC core spec provides guidelines for the use of some common RDF 
properties, including those from the Dublin Core. [1] dcterms:title and 
dcterms:description in general contain text that may include formatting 
information. There were several candidates for syntax - HTML, Wiki, RTF. 
The RDF spec contains the means for including XML literals, and XHTML is 
the W3C standard for formatted text. All the other text formats are 
convertible to XHTML. It was therefore chosen as the recommended way to 
package rich text.

The historical design of Jazz compact rendering is optimized for 
consumption by web browsers. However, the RDF plain text datatype does NOT 
imply that the text is HTML encoded. Another processor would be justified 
in displaying the verbatim encoding.

However, for the case of OSLC preview, I see no reason why the text 
couldn't be encoded, but it should be put in a property that makes that 
clear, e.g. oslc:htmlEncodedTitle.

FYI, I work on Focal Point and its REST API provides both a plain text and 
a marked up text version of some attributes.

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

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Adam Archer/Toronto/IBM
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Samuel Padgett <spadgett at us.ibm.com>, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:
08/22/2011 05:00 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at).

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:   Arthur Ryman/Toronto/IBM
To:     Samuel Padgett <spadgett at us.ibm.com>
Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From spadgett at us.ibm.com  Tue Aug 23 11:11:38 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Tue, 23 Aug 2011 11:11:38 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
Message-ID: <OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@us.ibm.com>

Hi, Arthur. Thanks for the answers. It clears some things up for me.

Arthur Ryman <ryman at ca.ibm.com> wrote on 08/22/2011 04:40:25 PM:

> I don't think problems using XPath are a valid reason to encode markup
> since RDF/XML itselt is very difficult to process using XPath. At one
> point we tried to define an OSLC-variant of RDF/XML that looked like
> "normal" XML. However, we abandonned that and now require support for
> generic RDF/XML.

To make sure I understand: By generic RDF/XML, you are talking about what
the spec calls "constrained RDF/XML" in Appendix B, right? [1]

> The are many equivalent ways to represent a given set of triples in
> RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
> XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
> RDF toolkit like Jena.

This makes sense, and I agree. But for me it also raises a few questions:

- Do we need a JSON Compact representation for consumers who don't use an
RDF library? This is one of the few resources in OSLC that doesn't have a
JSON representation, and it seems natural since so often the consumer here
is a web client.

- Should we define a "constrained RDF/XML" representation if our
recommendation is to use an RDF toolkit anyway? JSON might be a reasonable
alternative for those who don't want RDF/XML.

Best Regards,
Sam

[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_application_xml



From hudsonr at us.ibm.com  Tue Aug 23 10:36:19 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Tue, 23 Aug 2011 10:36:19 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
	<OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
	<OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>
Message-ID: <OF9BE55011.703713F3-ON852578F5.004E4930-852578F5.00503AAD@us.ibm.com>

I don't think the value's datatype is the same as the parseType.  The data
is [X]HTML, no matter what.  It is typically encoded, because that's the
way you store a value in XML, and as long as you follow standard XML
practice, using XPath to extract it has been pretty straightforward.  For
better or worse, RDF/XML supports the use of parseType, but many OSLC
consumers out there today are not going to handle documents that chose to
use parseType.

Also, the value really needs to be a snippet of HTML, not XHTML.  Existing
consumers are taking the value as if it were HTML and putting (after
sanitizing) it directly in an existing HTML page.  I'm sure there would be
problems consuming an XHTML snippet, for example, one that chose to assign
the XHTML to a non-default namespace.

FWIW, there are other places where OSLC deviates from what RDF/XML allows.
e.g., requiring the use of absolute URIs.

-Randy



|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" <oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel       |
  |Padgett/Durham/IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS                                                                                      |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/22/2011 04:55 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Randy,

I think example [3] is wrong. If the datatype is plain text then you
should not assume it contains encoded HTML. If you need to include markup
then you should use XML Literal datatype, and use XHTML content. This is
described in the core spec [4] which gives guidance for putting markup in
dcterms:title and dcterms:description.

[4]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties


Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube







From:
Randy Hudson <hudsonr at us.ibm.com>
To:
Samuel Padgett <spadgett at us.ibm.com>, Steve K Speicher
<sspeiche at us.ibm.com>
Cc:
Adam Archer/Toronto/IBM at IBMCA, "oslc-core at open-services.net"
<oslc-core at open-services.net>
Date:
08/08/2011 11:54 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be
wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |Samuel Padgett/Durham/IBM                              |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| To:        |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |oslc-core at open-services.net <oslc-core at open-services.net>            |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Cc:        |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA
                   |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Date:      |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |08/07/2011 01:06 PM                        |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Subject:   |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |OSLC Compact representation, titles with markup         |

>--------------------------------------------------------------------------------------------------------------------------------------------------|





Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net







From agarcher at ca.ibm.com  Tue Aug 23 11:35:57 2011
From: agarcher at ca.ibm.com (Adam Archer)
Date: Tue, 23 Aug 2011 11:35:57 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.004F6D01@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
	<OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.004F6D01@LocalDomain>
Message-ID: <OFD60830E3.3177897D-ON852578F5.00553E12-852578F5.0055B063@ca.ibm.com>

Arthur,

I understand that OSLC is taking a larger problem domain into account when 
defining syntax and data types, but I'm not arguing about that. I'm 
arguing that in the specific case of the compact spec, it makes it much 
less consumable. Generalizing is not always a good thing if it makes life 
more difficult for some of the cases. Perhaps what you are suggesting with 
the oslc:htmlEncodedTitle idea is the right way to address this, but all 
I'm advocating is that we not make this more complicated for consumers 
than it has been for the last 3 years. If that means a change to the spec, 
so be it.

Adam Archer
Jazz Developer
IBM Toronto Lab



From:   Arthur Ryman/Toronto/IBM
To:     Adam Archer/Toronto/IBM at IBMCA
Cc:     Randy Hudson <hudsonr at us.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel 
Padgett <spadgett at us.ibm.com>
Date:   08/23/2011 10:40 AM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Adam,

Your argument for escaping HTML is based purely on the use case of compact 
rendering. However, the OSLC specs are designed to enable many other use 
cases and to promote general interoperability among different tools.

The OSLC core spec provides guidelines for the use of some common RDF 
properties, including those from the Dublin Core. [1] dcterms:title and 
dcterms:description in general contain text that may include formatting 
information. There were several candidates for syntax - HTML, Wiki, RTF. 
The RDF spec contains the means for including XML literals, and XHTML is 
the W3C standard for formatted text. All the other text formats are 
convertible to XHTML. It was therefore chosen as the recommended way to 
package rich text.

The historical design of Jazz compact rendering is optimized for 
consumption by web browsers. However, the RDF plain text datatype does NOT 
imply that the text is HTML encoded. Another processor would be justified 
in displaying the verbatim encoding.

However, for the case of OSLC preview, I see no reason why the text 
couldn't be encoded, but it should be put in a property that makes that 
clear, e.g. oslc:htmlEncodedTitle.

FYI, I work on Focal Point and its REST API provides both a plain text and 
a marked up text version of some attributes.

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

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Adam Archer/Toronto/IBM
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Samuel Padgett <spadgett at us.ibm.com>, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:
08/22/2011 05:00 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at).

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:   Arthur Ryman/Toronto/IBM
To:     Samuel Padgett <spadgett at us.ibm.com>
Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110823/9ba80559/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0007.gif>

From sspeiche at us.ibm.com  Tue Aug 23 12:09:21 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 23 Aug 2011 12:09:21 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@us.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
	<OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@us.ibm.com>
Message-ID: <OF44A54CE2.FBFEAA8D-ON852578F5.00584E63-852578F5.0058BF38@us.ibm.com>

One thing I was going to point out, that the only representation supported 
is XML for Compact (not RDF/XML or JSON).

"The Compact representation MUST be in the XML format described in this 
document" 

I've queued this discussion as an issue to be discussed in Core WG

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


oslc-core-bounces at open-services.net wrote on 08/23/2011 11:11:38 AM:

> From: Samuel Padgett/Durham/IBM at IBMUS
> To: Arthur Ryman <ryman at ca.ibm.com>, 
> Cc: Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-
> core at open-services.net>, Randy Hudson/Raleigh/IBM at IBMUS, oslc-core-
> bounces at open-services.net
> Date: 08/23/2011 11:24 AM
> Subject: Re: [oslc-core] OSLC Compact representation, titles with markup
> Sent by: oslc-core-bounces at open-services.net
> 
> Hi, Arthur. Thanks for the answers. It clears some things up for me.
> 
> Arthur Ryman <ryman at ca.ibm.com> wrote on 08/22/2011 04:40:25 PM:
> 
> > I don't think problems using XPath are a valid reason to encode markup
> > since RDF/XML itselt is very difficult to process using XPath. At one
> > point we tried to define an OSLC-variant of RDF/XML that looked like
> > "normal" XML. However, we abandonned that and now require support for
> > generic RDF/XML.
> 
> To make sure I understand: By generic RDF/XML, you are talking about 
what
> the spec calls "constrained RDF/XML" in Appendix B, right? [1]
> 
> > The are many equivalent ways to represent a given set of triples in
> > RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
> > XQuery to process RDF/XML. The safe way to process RDF/XML is to use 
an
> > RDF toolkit like Jena.
> 
> This makes sense, and I agree. But for me it also raises a few 
questions:
> 
> - Do we need a JSON Compact representation for consumers who don't use 
an
> RDF library? This is one of the few resources in OSLC that doesn't have 
a
> JSON representation, and it seems natural since so often the consumer 
here
> is a web client.
> 
> - Should we define a "constrained RDF/XML" representation if our
> recommendation is to use an RDF toolkit anyway? JSON might be a 
reasonable
> alternative for those who don't want RDF/XML.
> 
> Best Regards,
> Sam
> 
> [1]
> 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?

> sortcol=table;up=#Guidelines_for_application_xml
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net



From spadgett at us.ibm.com  Tue Aug 23 15:14:01 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Tue, 23 Aug 2011 15:14:01 -0400
Subject: [oslc-core] Minor problem in JSON Service Provider Resource example
Message-ID: <OF668F4399.44D2378F-ON852578F5.0068F15E-852578F5.0069B312@us.ibm.com>


Minor problem in the JSON Service Provider Resource example [1]: It looks
like 'service' should be 'oslc:service', and the value should be a JSON
array rather than a JSON object since it occurs 'one-or-many' [2].

- Best Regards, Sam

[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecJSONExamples?sortcol=table;up=#Service_Provider_Resource
[2]
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Service_Provider_Resources



From ryman at ca.ibm.com  Tue Aug 23 15:14:51 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 23 Aug 2011 15:14:51 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFD60830E3.3177897D-ON852578F5.00553E12-852578F5.00559CCB@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
	<OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.004F6D01@LocalDomain>
	<OFD60830E3.3177897D-ON852578F5.00553E12-852578F5.00559CCB@LocalDomain>
Message-ID: <OF9A5008D5.3F2D2835-ON852578F5.006973E3-852578F5.0069BAD4@ca.ibm.com>


Adam,

Yes, I am suggesting that when people use dcterms:title they represent
markup via XML Literal rather than HTML encoding. It think it would be
cleaner to use a special purpose property for literals that were encoded
HTML, e.g. oslc:htmlEncodedTitle.

Regards,
___________________________________________________________________________
                                                                               
 Arthur Ryman                                                                  
                                                                               
 DE, PPM Chief Architect                                                       
                                                                               
 IBM Software, Rational                                                        
                                                                               
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |  
                                                                      YouTube  
                                                                               
                                                                               
                                                                               




|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer/Toronto/IBM                                                                                                                           |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman/Toronto/IBM at IBMCA                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson <hudsonr at us.ibm.com>, "oslc-core at open-services.net" <oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel       |
  |Padgett <spadgett at us.ibm.com>                                                                                                                     |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/23/2011 11:35 AM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Arthur,

I understand that OSLC is taking a larger problem domain into account when
defining syntax and data types, but I'm not arguing about that. I'm arguing
that in the specific case of the compact spec, it makes it much less
consumable. Generalizing is not always a good thing if it makes life more
difficult for some of the cases. Perhaps what you are suggesting with the
oslc:htmlEncodedTitle idea is the right way to address this, but all I'm
advocating is that we not make this more complicated for consumers than it
has been for the last 3 years. If that means a change to the spec, so be
it.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:	Arthur Ryman/Toronto/IBM
To:	Adam Archer/Toronto/IBM at IBMCA
Cc:	Randy Hudson <hudsonr at us.ibm.com>,
            "oslc-core at open-services.net" <oslc-core at open-services.net>,
            oslc-core-bounces at open-services.net, Samuel Padgett
            <spadgett at us.ibm.com>
Date:	08/23/2011 10:40 AM
Subject:	Re: [oslc-core] OSLC Compact representation, titles with markup


Adam,

Your argument for escaping HTML is based purely on the use case of compact
rendering. However, the OSLC specs are designed to enable many other use
cases and to promote general interoperability among different tools.

The OSLC core spec provides guidelines for the use of some common RDF
properties, including those from the Dublin Core. [1] dcterms:title and
dcterms:description in general contain text that may include formatting
information. There were several candidates for syntax - HTML, Wiki, RTF.
The RDF spec contains the means for including XML literals, and XHTML is
the W3C standard for formatted text. All the other text formats are
convertible to XHTML. It was therefore chosen as the recommended way to
package rich text.

The historical design of Jazz compact rendering is optimized for
consumption by web browsers. However, the RDF plain text datatype does NOT
imply that the text is HTML encoded. Another processor would be justified
in displaying the verbatim encoding.

However, for the case of OSLC preview, I see no reason why the text
couldn't be encoded, but it should be put in a property that makes that
clear, e.g. oslc:htmlEncodedTitle.

FYI, I work on Focal Point and its REST API provides both a plain text and
a marked up text version of some attributes.

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

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |   
                                                                      YouTube   
                                                                                
                                                                                
                                                                                





|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer/Toronto/IBM                                                                                                                           |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman/Toronto/IBM at IBMCA                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett <spadgett at us.ibm.com>, Randy Hudson <hudsonr at us.ibm.com>, "oslc-core at open-services.net" <oslc-core at open-services.net>,             |
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/22/2011 05:00 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




The big concern to me is not the ability to process the RDF/XML with XPath,
it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply taking
the content of the attribute, decoding it (which browsers are very good at)
and slapping the result into the dom (which browsers are also very good
at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I don't
even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine what
the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:	Arthur Ryman/Toronto/IBM
To:	Samuel Padgett <spadgett at us.ibm.com>
Cc:	Adam Archer/Toronto/IBM at IBMCA, Randy Hudson
            <hudsonr at us.ibm.com>, "oslc-core at open-services.net"
            <oslc-core at open-services.net>,
            oslc-core-bounces at open-services.net
Date:	08/22/2011 04:40 PM
Subject:	Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one point
we tried to define an OSLC-variant of RDF/XML that looked like "normal"
XML. However, we abandonned that and now require support for generic
RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an RDF
toolkit like Jena.

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |   
                                                                      YouTube   
                                                                                
                                                                                
                                                                                





|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett <spadgett at us.ibm.com>                                                                                                              |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"oslc-core at open-services.net" <oslc-core at open-services.net>                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:01 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |[oslc-core] OSLC Compact representation, titles with markup                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|






I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110823/ebec2025/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12845780.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12047798.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0007.gif>

From davidms at ca.ibm.com  Wed Aug 24 15:01:19 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Wed, 24 Aug 2011 15:01:19 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
Message-ID: <OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>


Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a
convenience, but only if tools supported that. As far as I could find, Jena
provides no fine-grained access to namespace declarations (i.e. other than
at the model level), so I believe that one couldn't use it to produce or
consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. That
was very helpful for me. But I must admit, I'm still left wondering what
makes XHTML superior to HTML for interchanging formatted text, especially
in light of the compact representation example and my own experiences,
where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so
odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of this
is acknowledged or explained anywhere. It looks like using a typed literal
in this one case is accepted merely as a requirement to benefit from the
prettier RDF/XML syntax for XML content. However, I view things completely
in the opposite light. To me, typed literals are a powerful benefit of RDF.
You can use a typed literal to decide how to handle a literal value,
without looking at the value itself, but that advantage is lost without a
sufficiently specific type. Thus, I don't understand how defining and using
a new RDF datatype to identify something as widely recognized and
understood as HTML would impair interoperability. I think it would do the
opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                             
  From:       Arthur Ryman/Toronto/IBM                                                                       
                                                                                                             
  To:         Dave Steinberg/Toronto/IBM at IBMCA                                                               
                                                                                                             
  Cc:         oslc-core at open-services.net, oslc-core-bounces at open-services.net                               
                                                                                                             
  Date:       08/23/2011 10:09 AM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             




Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF
datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The
parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. There
are converter from HTML to XHTML, e.g. Tidy. However, in the case of
preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.
However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF etc.
would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged
since it impairs interoperability.

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

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |   
                                                                      YouTube   
                                                                                
                                                                                
                                                                                





                                                                                                             
  From:       Dave Steinberg/Toronto/IBM at IBMCA                                                               
                                                                                                             
  To:         oslc-core at open-services.net                                                                    
                                                                                                             
  Date:       08/23/2011 12:06 AM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             
  Sent by:    oslc-core-bounces at open-services.net                                                            
                                                                                                             





Hi all,

I've been following this thread with interest, as it touches on some of the
more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated as
a simple string or as HTML content. And that's the very thing that typed
literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type is
supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types in
both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than XMLLiteral
eliminates the "benefit" of the special rdf:parseType="Literal" syntax. And
without that, I don't see a particular benefit in the stricter XHTML
syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I believe
that, strictly, the XHTML namespace is required for the elements to be
valid XHTML. But I found no hint of this in the spec or any examples, and
certainly RTC doesn't do this (I haven't checked other providers).
Moreover, I believe it's also a worse approach, since there's no guarantee
that your RDF runtime of choice will give you access to namespaces declared
on the property element (I don't believe Jena does), and detecting a
namespace inside the element content would require actually parsing the
value as XML. If all you want to do is pass markup along for display in a
browser, it would be unfortunate to have to actually parse the content to
determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably just
as good as, if not better than, XHTML. Rather than worrying about whether
the content is well-formed XML, it's probably sufficient to just give it to
the browser and see what it can do with it. I would assert that "something
a browser can render" has been the working definition of HTML for a good
number of years now, while XHTML has largely faded in importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it via
OSLC. Likewise, a consumer may use a rich text control that yields HTML.
Generalized parsing of HTML for conversion to XHTML is non-trivial, and it
seems unfortunate to impose that conversion task onto everyone, just so
that we can use rdf:parseType="Literal" in RDF/XML and avoid applying
normal XML encoding to markup content (of course, some encoding will likely
be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if they
all do make perfect sense (and I'm not necessarily claiming they do), I
realize we may be well past the point of being able to act on them. Still,
I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property needed
to change. This is a related, but separate, topic, which I'd be thrilled to
discuss further, but I don't want to open too many cans of worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Inactive hide details for Adam Archer---08/22/2011 06:20:05 PM---The big
concern to me is not the ability to process the RDF/XMAdam
Archer---08/22/2011 06:20:05 PM---The big concern to me is not the ability
to process the RDF/XML with XPath, it's the ability to do
                                                                           
                                                                           
 From:    Adam Archer/Toronto/IBM at IBMCA                                    
                                                                           
                                                                           
 To:      Arthur Ryman/Toronto/IBM at IBMCA                                   
                                                                           
                                                                           
 Cc:      "oslc-core at open-services.net" <oslc-core at open-services.net>,     
          Randy Hudson <hudsonr at us.ibm.com>,                               
          oslc-core-bounces at open-services.net                              
                                                                           
                                                                           
 Date:    08/22/2011 06:20 PM                                              
                                                                           
                                                                           
 Subject: Re: [oslc-core] OSLC Compact representation, titles with markup  
                                                                           
                                                                           
 Sent by: oslc-core-bounces at open-services.net                              
                                                                           





The big concern to me is not the ability to process the RDF/XML with XPath,
it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply taking
the content of the attribute, decoding it (which browsers are very good at)
and slapping the result into the dom (which browsers are also very good
at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I don't
even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine what
the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one point
we tried to define an OSLC-variant of RDF/XML that looked like "normal"
XML. However, we abandonned that and now require support for generic
RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an RDF
toolkit like Jena.

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                   Twitter | Facebook | YouTube   
                                                                                
                                                                                
                                                                                




                                                                           
 From:   Samuel Padgett <spadgett at us.ibm.com>                              
                                                                           
 To:     "oslc-core at open-services.net" <oslc-core at open-services.net>       
                                                                           
 Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>  
                                                                           
 Date:   08/07/2011 01:01 PM                                               
                                                                           
 Subject [oslc-core] OSLC Compact representation, titles with markup       
 :                                                                         
                                                                           
 Sent    oslc-core-bounces at open-services.net                               
 by:                                                                       
                                                                           







I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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

_______________________________________________
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/20110824/f29be9da/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16248338.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16539910.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0007.gif>

From sspeiche at us.ibm.com  Wed Aug 24 15:13:24 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Wed, 24 Aug 2011 15:13:24 -0400
Subject: [oslc-core] OSLC Core WG Minutes: August 24, 2011
Message-ID: <OF0BB3350E.4EE7A509-ON852578F6.0069422A-852578F6.00699900@us.ibm.com>

http://open-services.net/bin/view/Main/OslcCoreMeeting20110824

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



From sspeiche at us.ibm.com  Wed Aug 24 15:41:11 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Wed, 24 Aug 2011 15:41:11 -0400
Subject: [oslc-core] OSLC Core WG Meeting Day/Time Survey -- Please Respond
Message-ID: <OFFFB1A464.E6A3D81D-ON852578F6.006B6AC9-852578F6.006C2440@us.ibm.com>

Survey link: http://doodle.com/n5bef5gepvx2fhaw

Using dates 2 weeks from now just as an example.  Pick a day/time of week 
that works, even if it doesn't work for this one week.

Let me know if there are any questions.

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



From ryman at ca.ibm.com  Thu Aug 25 16:32:02 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Thu, 25 Aug 2011 16:32:02 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
Message-ID: <OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>

Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 
http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 
literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 
There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 
suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 
it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 
convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 
than at the model level), so I believe that one couldn't use it to produce 
or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 
odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 
datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 
parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 
preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 
However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 
since it impairs interoperability.

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


Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 
thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 
use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 
of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 
a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 
in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 
XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 
note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 
syntax. And without that, I don't see a particular benefit in the stricter 
XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 
consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 
"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 
I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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

_______________________________________________
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





From ryman at ca.ibm.com  Thu Aug 25 16:47:05 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Thu, 25 Aug 2011 16:47:05 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
	<OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@LocalDomain>
Message-ID: <OF8B61EA2A.1229F837-ON852578F7.00708173-852578F7.00722E69@ca.ibm.com>

Sam,

By "generic RDF/XML" I mean arbitrary, unconstrained RDF/XML. We started 
out trying to define a constrained RDF/XML for general use because we 
thought it would be easier to parse with standard XML technologies. 
However, we did not want to pay the price of defining this precisely, 
having a validator, etc. We soon found it was very hard to entice toolkits 
to generate RDF/XML that precisely fit our design. The closest we came was 
the so-called Abbreviated RDF/XML in Jena. There was no spec for that. I 
assume it's just supposed to be easier to read by humans. In the end we 
decided to abandon that approach and simply adopt the W3C RDF/XML spec.

However, as a legacy, that compact UI spec still used the constrained 
RDF/XML. However, we don't call it RDF. It's content type is 
application/xml. It just happens to also be valid RDF/XML but service 
providers are not allowed to use unconstrained RDF/XML. They have to 
generate precisely that format. We could even have written an XSD to 
describe the format. The goal was to make it easy to parse in browsers, 
i.e. not require full browser-based RDF parsers.

Yes, it would have made sense to use JSON for this purpose since browsers 
can more easily parse that. However, as a general rule, we want to 
minimize the number of formats a service provider has to support. This XML 
format is a MUST.

___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Samuel Padgett/Durham/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Randy 
Hudson/Raleigh/IBM at IBMUS
Date:
08/23/2011 11:12 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Hi, Arthur. Thanks for the answers. It clears some things up for me.

Arthur Ryman <ryman at ca.ibm.com> wrote on 08/22/2011 04:40:25 PM:

> I don't think problems using XPath are a valid reason to encode markup 
> since RDF/XML itselt is very difficult to process using XPath. At one 
> point we tried to define an OSLC-variant of RDF/XML that looked like 
> "normal" XML. However, we abandonned that and now require support for 
> generic RDF/XML.

To make sure I understand: By generic RDF/XML, you are talking about what 
the spec calls "constrained RDF/XML" in Appendix B, right? [1]

> The are many equivalent ways to represent a given set of triples in 
> RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
> XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
> RDF toolkit like Jena.

This makes sense, and I agree. But for me it also raises a few questions:

- Do we need a JSON Compact representation for consumers who don't use an 
RDF library? This is one of the few resources in OSLC that doesn't have a 
JSON representation, and it seems natural since so often the consumer here 
is a web client.

- Should we define a "constrained RDF/XML" representation if our 
recommendation is to use an RDF toolkit anyway? JSON might be a reasonable 
alternative for those who don't want RDF/XML.

Best Regards,
Sam

[1] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_application_xml




From ryman at ca.ibm.com  Thu Aug 25 16:47:05 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Thu, 25 Aug 2011 16:47:05 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF9BE55011.703713F3-ON852578F5.004E4930-852578F5.00503AAD@LocalDomain>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
	<OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
	<OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>
	<OF9BE55011.703713F3-ON852578F5.004E4930-852578F5.00503AAD@LocalDomain>
Message-ID: <OF5FCD697E.449D13FA-ON852578F7.00719240-852578F7.00722E6C@ca.ibm.com>

Randy,

OSLC now supports W3C RDF/XML. This means all URIs are absolute although 
you  might compute them relative to the xml:base. But that is standard 
RDF/XML. Do you have an example where OSLC deviates from RDF/XML?

In RDF/XML the attribute rdf:parseType="Literal" means that the datatype 
is XMLLiteral.

I think I addressed your other comments in other responses.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel 
Padgett/Durham/IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS
Date:
08/23/2011 10:36 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


I don't think the value's datatype is the same as the parseType.  The data 
is [X]HTML, no matter what.  It is typically encoded, because that's the 
way you store a value in XML, and as long as you follow standard XML 
practice, using XPath to extract it has been pretty straightforward.  For 
better or worse, RDF/XML supports the use of parseType, but many OSLC 
consumers out there today are not going to handle documents that chose to 
use parseType.

Also, the value really needs to be a snippet of HTML, not XHTML.  Existing 
consumers are taking the value as if it were HTML and putting (after 
sanitizing) it directly in an existing HTML page.  I'm sure there would be 
problems consuming an XHTML snippet, for example, one that chose to assign 
the XHTML to a non-default namespace.

FWIW, there are other places where OSLC deviates from what RDF/XML allows. 
 e.g., requiring the use of absolute URIs.

-Randy





From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel 
Padgett/Durham/IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS
Date:
08/22/2011 04:55 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

I think example [3] is wrong. If the datatype is plain text then you 
should not assume it contains encoded HTML. If you need to include markup 
then you should use XML Literal datatype, and use XHTML content. This is 
described in the core spec [4] which gives guidance for putting markup in 
dcterms:title and dcterms:description.

[4] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties


Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Randy Hudson <hudsonr at us.ibm.com>
To:
Samuel Padgett <spadgett at us.ibm.com>, Steve K Speicher 
<sspeiche at us.ibm.com>
Cc:
Adam Archer/Toronto/IBM at IBMCA, "oslc-core at open-services.net" 
<oslc-core at open-services.net>
Date:
08/08/2011 11:54 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be 
wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett/Durham/IBM                              |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net <oslc-core at open-services.net>            |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA 
                   |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:06 PM                        |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSLC Compact representation, titles with markup         |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net








From hudsonr at us.ibm.com  Thu Aug 25 19:06:45 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Thu, 25 Aug 2011 19:06:45 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
Message-ID: <OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@us.ibm.com>

The following input is also equivalent:

<dcterms:title
rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
12345: &lt;s xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception
during startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value of
type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
      1.2.1 Inside the XML element add the value as a string with any
      required escaping

That would seem to suggest that the above form should be used.

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/25/2011 04:34 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for
http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the
literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.
There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test
suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,
it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a
convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other
than at the model level), so I believe that one couldn't use it to produce
or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so
odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF
datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The
parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of
preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.
However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged
since it impairs interoperability.

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



Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this
thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"
syntax. And without that, I don't see a particular benefit in the stricter
XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that
"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),
I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From joeross at us.ibm.com  Thu Aug 25 19:30:38 2011
From: joeross at us.ibm.com (Joe Ross)
Date: Thu, 25 Aug 2011 18:30:38 -0500
Subject: [oslc-core] domain URL for Service that supports creation/query of
 Service Provider resources
Message-ID: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>

In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 
We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability.

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec.

Thanks much,

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110825/e23c8a5e/attachment.html>

From ryman at ca.ibm.com  Fri Aug 26 07:59:58 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 07:59:58 -0400
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
Message-ID: <OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>

Joe,

Your Service Provider registry service sounds interesting.

I am a little concerned about you using http://open-services.net/ns/core# 
as the domain since we haven't specified what that would mean. Here is the 
definition of  what a Domain is:

OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
Management, Requirements management or Automation. Each OSLC Domain will 
have its own OSLC specification that complies with this Core 
specification. 

I think we should have a spec that outlines the types of resources in the 
domain. You have selected just one type of  core resource.  Perhaps you 
should specify that and coin a URI for it?

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net
Date:
08/25/2011 10:49 PM
Subject:
[oslc-core] domain URL for Service that supports creation/query of Service 
Provider resources
Sent by:
oslc-core-bounces at open-services.net




In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 
We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability. 

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec. 

Thanks much, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From sspeiche at us.ibm.com  Fri Aug 26 09:08:21 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Fri, 26 Aug 2011 09:08:21 -0400
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
Message-ID: <OF45B1D423.FDCDF929-ON852578F8.0047766A-852578F8.00482D21@us.ibm.com>

Agree that this sounds like an interesting registry.  I also agree that 
what the spec says is quite restrictive in the sense of: 1) it doesn't 
allow for providers that don't fit any domain and 2) along these same 
lines, doesn't allow for pre-spec or proprietary explorations to introduce 
"private domains".

To accommodate these two cases, I see 3 different alternatives:
a. Just use the core namespace as Joe suggested
b. Invent a "private domain" namespace and use that
c. Create an OSLC WG, create a spec to support this, then use that 
namespace

Doing (a) requires us to modify the definition or intention in the spec, 
which I think is the most desirable.  Doing (b) has nice qualities but 
again would make use issue some changes to the spec.  Finally (c) is what 
we have today but requires a little overhead.

If there is the possibility of tweaking the spec, not making oslc:domain 
required on oslc:Service.  Though this has some breaking possibilities 
that we should avoid.  I believe the other options mentioned provide for 
the desired use case without impacting many, if any, clients.

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


> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Joe Ross/Austin/IBM at IBMUS, 
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 08/26/2011 08:00 AM
> Subject: Re: [oslc-core] domain URL for Service that supports 
creation/query
> of Service Provider resources
> Sent by: oslc-core-bounces at open-services.net
> 
> Joe,
> 
> Your Service Provider registry service sounds interesting.
> 
> I am a little concerned about you using 
http://open-services.net/ns/core# 
> as the domain since we haven't specified what that would mean. Here is 
the 
> definition of  what a Domain is:
> 
> OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
> Management, Requirements management or Automation. Each OSLC Domain will 

> have its own OSLC specification that complies with this Core 
> specification. 
> 
> I think we should have a spec that outlines the types of resources in 
the 
> domain. You have selected just one type of  core resource.  Perhaps you 
> should specify that and coin a URI for it?
> 
> Regards, 
> 
___________________________________________________________________________ 

> 
> Arthur Ryman 
> 
> DE, PPM & Reporting Chief Architect
> IBM Software, Rational 
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 
> 
> 
> 
> 
> 
> From:
> Joe Ross <joeross at us.ibm.com>
> To:
> oslc-core at open-services.net
> Date:
> 08/25/2011 10:49 PM
> Subject:
> [oslc-core] domain URL for Service that supports creation/query of 
Service 
> Provider resources
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> 
> In Tivoli, we are creating a Provider Registry that is itself 
implemented 
> as a Service Provider (a Service Provider for Service Provider 
resources). 
> We want to do this, so that we can support creation of Service Provider 
> records using a Creation Factory and querying for Service Providers 
using 
> a Query Capability. 
> 
> As part of defining the Service, we need to provide an oslc:domain with 
> namespace URI. Does it make sense for us to use the OSLC Core namespace 
> URI  (http://open-services.net/ns/core# ) for this? That seems logical 
> since all of the resources we are supporting in this Provider Registry 
> Service Provider are defined in the OSLC Core spec. 
> 
> Thanks much, 
> 
> ================================================
> Joe Ross/Austin/IBM, joeross at us.ibm.com
> Tivoli Autonomic Computing & Component Technologies
> 512-286-8311, T/L 
363-8311_______________________________________________
> 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



From sspeiche at us.ibm.com  Fri Aug 26 09:25:39 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Fri, 26 Aug 2011 09:25:39 -0400
Subject: [oslc-core] Minor problem in JSON Service Provider Resource
	example
In-Reply-To: <OF668F4399.44D2378F-ON852578F5.0068F15E-852578F5.0069B312@us.ibm.com>
References: <OF668F4399.44D2378F-ON852578F5.0068F15E-852578F5.0069B312@us.ibm.com>
Message-ID: <OFD093B94B.320C13F5-ON852578F8.00492FF1-852578F8.0049C29B@us.ibm.com>

Thanks Sam, made the fix.  After a quick sanity check, I also noticed that 
oslc:queryCapabilty has the same issue as oslc:service (should be an 
array).  Also the oslc:resourceShape (also renamed from oslc:shap) were 
objects and not arrays.  Think I fixed all the issues with it.  I also ran 
it through jslint.org to make sure it was valid still.

Let me know if I missed anything.

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

> From: Samuel Padgett/Durham/IBM at IBMUS
> To: "oslc-core at open-services.net" <oslc-core at open-services.net>, 
> Cc: Kevin Bauer/Raleigh/IBM at IBMUS
> Date: 08/23/2011 03:15 PM
> Subject: [oslc-core] Minor problem in JSON Service Provider Resource 
example
> Sent by: oslc-core-bounces at open-services.net
> 
> 
> Minor problem in the JSON Service Provider Resource example [1]: It 
looks
> like 'service' should be 'oslc:service', and the value should be a JSON
> array rather than a JSON object since it occurs 'one-or-many' [2].
> 
> - Best Regards, Sam
> 
> [1]
> http://open-services.net/bin/view/Main/OSLCCoreSpecJSONExamples?
> sortcol=table;up=#Service_Provider_Resource
> [2]
> http://open-services.net/bin/view/Main/OslcCoreSpecification?
> sortcol=table;up=#Service_Provider_Resources
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 



From joeross at us.ibm.com  Fri Aug 26 09:50:24 2011
From: joeross at us.ibm.com (Joe Ross)
Date: Fri, 26 Aug 2011 08:50:24 -0500
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
Message-ID: <OFBB321C85.89A8EB60-ON862578F8.004B0E99-862578F8.004C0787@us.ibm.com>

Arthr,

We are actually  representing most (if not all) of the core resource types 
(Service, CreationFactory, QueryCapability, etc.) in the Provider Registry 
records.  Basically products register all of their capabilities and access 
points by OSLC core resource records in the Provider Registry. Most of the 
resources are in-line and part of the complete Service Provider record 
being registered. We will probably also need to register Resource Shapes 
and their properties for a complete understanding of provider 
capabilities.

Since these resource types are already defined in the Core specification, 
I would prefer not to have to redefine them all in a domain spec. 

Thanks,

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311



From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Joe Ross/Austin/IBM at IBMUS
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/26/2011 07:00 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources



Joe,

Your Service Provider registry service sounds interesting.

I am a little concerned about you using http://open-services.net/ns/core# 
as the domain since we haven't specified what that would mean. Here is the 

definition of  what a Domain is:

OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
Management, Requirements management or Automation. Each OSLC Domain will 
have its own OSLC specification that complies with this Core 
specification. 

I think we should have a spec that outlines the types of resources in the 
domain. You have selected just one type of  core resource.  Perhaps you 
should specify that and coin a URI for it?

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net
Date:
08/25/2011 10:49 PM
Subject:
[oslc-core] domain URL for Service that supports creation/query of Service 

Provider resources
Sent by:
oslc-core-bounces at open-services.net




In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 

We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability. 

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec. 

Thanks much, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
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/20110826/9db92abb/attachment-0001.html>

From ryman at ca.ibm.com  Fri Aug 26 10:04:31 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 10:04:31 -0400
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OFBB321C85.89A8EB60-ON862578F8.004B0E99-862578F8.004C0787@LocalDomain>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
	<OFBB321C85.89A8EB60-ON862578F8.004B0E99-862578F8.004C0787@LocalDomain>
Message-ID: <OF8A61BF8D.10B96647-ON852578F8.004C38F7-852578F8.004D52E2@ca.ibm.com>

Joe,

I didn't mean to imply you should redefine them. Just reference the core 
spec. Currently, the core spec isn't technically a domain. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross/Austin/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/26/2011 09:50 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources




Arthr, 

We are actually  representing most (if not all) of the core resource types 
(Service, CreationFactory, QueryCapability, etc.) in the Provider Registry 
records.  Basically products register all of their capabilities and access 
points by OSLC core resource records in the Provider Registry. Most of the 
resources are in-line and part of the complete Service Provider record 
being registered. We will probably also need to register Resource Shapes 
and their properties for a complete understanding of provider 
capabilities. 

Since these resource types are already defined in the Core specification, 
I would prefer not to have to redefine them all in a domain spec. 

Thanks, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311 


From: 
Arthur Ryman <ryman at ca.ibm.com> 
To: 
Joe Ross/Austin/IBM at IBMUS 
Cc: 
oslc-core at open-services.net, oslc-core-bounces at open-services.net 
Date: 
08/26/2011 07:00 AM 
Subject: 
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources




Joe,

Your Service Provider registry service sounds interesting.

I am a little concerned about you using http://open-services.net/ns/core# 
as the domain since we haven't specified what that would mean. Here is the 

definition of  what a Domain is:

OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
Management, Requirements management or Automation. Each OSLC Domain will 
have its own OSLC specification that complies with this Core 
specification. 

I think we should have a spec that outlines the types of resources in the 
domain. You have selected just one type of  core resource.  Perhaps you 
should specify that and coin a URI for it?

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net
Date:
08/25/2011 10:49 PM
Subject:
[oslc-core] domain URL for Service that supports creation/query of Service 

Provider resources
Sent by:
oslc-core-bounces at open-services.net




In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 

We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability. 

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec. 

Thanks much, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net









From joeross at us.ibm.com  Fri Aug 26 10:00:31 2011
From: joeross at us.ibm.com (Joe Ross)
Date: Fri, 26 Aug 2011 09:00:31 -0500
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF45B1D423.FDCDF929-ON852578F8.0047766A-852578F8.00482C13@LocalDomain>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
	<OF45B1D423.FDCDF929-ON852578F8.0047766A-852578F8.00482C13@LocalDomain>
Message-ID: <OFE49732DE.42E52B2F-ON862578F8.004BDA7D-862578F8.004CF4BD@us.ibm.com>

Steve,

We would  really prefer option (a). although I guess we could use option 
(b) informally, until necessary spec work is done. I don't think that we 
want to redefine all of the core resource types in another domain.

Even if oslc:domain is not required, there needs to be some property to 
allow clients to understand what kind of Service this is. We are planning 
to use domain to allow clients to select the Service they want to interact 
with.

Thanks,

Joe

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311



From:
Steve K Speicher/Raleigh/IBM
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Joe Ross/Austin/IBM at IBMUS, oslc-core at open-services.net
Date:
08/26/2011 08:08 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources


Agree that this sounds like an interesting registry.  I also agree that 
what the spec says is quite restrictive in the sense of: 1) it doesn't 
allow for providers that don't fit any domain and 2) along these same 
lines, doesn't allow for pre-spec or proprietary explorations to introduce 
"private domains".

To accommodate these two cases, I see 3 different alternatives:
a. Just use the core namespace as Joe suggested
b. Invent a "private domain" namespace and use that
c. Create an OSLC WG, create a spec to support this, then use that 
namespace

Doing (a) requires us to modify the definition or intention in the spec, 
which I think is the most desirable.  Doing (b) has nice qualities but 
again would make use issue some changes to the spec.  Finally (c) is what 
we have today but requires a little overhead.

If there is the possibility of tweaking the spec, not making oslc:domain 
required on oslc:Service.  Though this has some breaking possibilities 
that we should avoid.  I believe the other options mentioned provide for 
the desired use case without impacting many, if any, clients.

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


> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Joe Ross/Austin/IBM at IBMUS, 
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 08/26/2011 08:00 AM
> Subject: Re: [oslc-core] domain URL for Service that supports 
creation/query
> of Service Provider resources
> Sent by: oslc-core-bounces at open-services.net
> 
> Joe,
> 
> Your Service Provider registry service sounds interesting.
> 
> I am a little concerned about you using 
http://open-services.net/ns/core# 
> as the domain since we haven't specified what that would mean. Here is 
the 
> definition of  what a Domain is:
> 
> OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
> Management, Requirements management or Automation. Each OSLC Domain will 

> have its own OSLC specification that complies with this Core 
> specification. 
> 
> I think we should have a spec that outlines the types of resources in 
the 
> domain. You have selected just one type of  core resource.  Perhaps you 
> should specify that and coin a URI for it?
> 
> Regards, 
> 
___________________________________________________________________________ 

> 
> Arthur Ryman 
> 
> DE, PPM & Reporting Chief Architect
> IBM Software, Rational 
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 
> 
> 
> 
> 
> 
> From:
> Joe Ross <joeross at us.ibm.com>
> To:
> oslc-core at open-services.net
> Date:
> 08/25/2011 10:49 PM
> Subject:
> [oslc-core] domain URL for Service that supports creation/query of 
Service 
> Provider resources
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> 
> In Tivoli, we are creating a Provider Registry that is itself 
implemented 
> as a Service Provider (a Service Provider for Service Provider 
resources). 
> We want to do this, so that we can support creation of Service Provider 
> records using a Creation Factory and querying for Service Providers 
using 
> a Query Capability. 
> 
> As part of defining the Service, we need to provide an oslc:domain with 
> namespace URI. Does it make sense for us to use the OSLC Core namespace 
> URI  (http://open-services.net/ns/core# ) for this? That seems logical 
> since all of the resources we are supporting in this Provider Registry 
> Service Provider are defined in the OSLC Core spec. 
> 
> Thanks much, 
> 
> ================================================
> Joe Ross/Austin/IBM, joeross at us.ibm.com
> Tivoli Autonomic Computing & Component Technologies
> 512-286-8311, T/L 
363-8311_______________________________________________
> 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/20110826/7fabc50c/attachment.html>

From ryman at ca.ibm.com  Fri Aug 26 14:22:28 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 14:22:28 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
Message-ID: <OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@ca.ibm.com>

Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 

it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 

convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 

than at the model level), so I believe that one couldn't use it to produce 

or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 

odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 

datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 

parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 

preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 

However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 

since it impairs interoperability.

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



Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 

use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 

of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 

a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 

in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 

XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 

note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 

syntax. And without that, I don't see a particular benefit in the stricter 

XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 

consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 

"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 

I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 

view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 

it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 

(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 

consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From hudsonr at us.ibm.com  Fri Aug 26 14:48:56 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Fri, 26 Aug 2011 14:48:56 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
Message-ID: <OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@us.ibm.com>

Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get
jena to write out the property this way by setting an option on the writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the value's
type in its serialized form in cases where only one datatype is allowed.
It looks like bits of the "schema" get repeated over and over.

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman/Toronto/IBM at IBMCA                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, oslc-core-bounces at open-services.net                                             |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/26/2011 02:22 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________
                                                                              
 Arthur Ryman                                        (Embedded image moved to 
                                                          file: pic19425.gif) 
                                                                              
 DE, PPM & Reporting Chief Architect                                          
                                                                              
 IBM Software, Rational                                                       
                                                                              
 Toronto Lab | +1-905-413-3077 (office) |                                     
 +1-416-939-5063 (mobile)                                                     
                                                                              





|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, oslc-core-bounces at open-services.net                                             |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/25/2011 07:06 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value of
type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
      1.2.1 Inside the XML element add the value as a string with any
      required escaping

That would seem to suggest that the above form should be used.

-Randy



|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/25/2011 04:34 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for
http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the
literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.
There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test
suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,
it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a
convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other
than at the model level), so I believe that one couldn't use it to produce
or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so
odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF
datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The
parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of
preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.
However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged
since it impairs interoperability.

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



Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this
thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"
syntax. And without that, I don't see a particular benefit in the stricter
XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that
"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),
I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic19425.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/b0ca3e53/attachment-0001.gif>

From davidms at ca.ibm.com  Fri Aug 26 15:21:02 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 15:21:02 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
Message-ID: <OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>


Arthur,

I believe you're mistaken. I think that parseType="Literal" is just
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make
it easy to write literals of this kind"). Either way you write it, you end
up with the same statement. Two statements with the same subject, the same
predicate and a typed literal with the same type
(<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with
some sort of privileged XMLLiteral representation that couldn't written out
using any other RDF notation.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com



                                                                                                             
  From:       Arthur Ryman/Toronto/IBM                                                                       
                                                                                                             
  To:         Randy Hudson/Raleigh/IBM at IBMUS                                                                 
                                                                                                             
  Cc:         Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,                              
              oslc-core-bounces at open-services.net                                                            
                                                                                                             
  Date:       08/26/2011 02:22 PM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             





Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,

it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a

convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other

than at the model level), so I believe that one couldn't use it to produce

or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so

odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF

datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The

parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of

preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.

However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged

since it impairs interoperability.

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




Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the

use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use

of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use

a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral

in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other

XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And

note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"

syntax. And without that, I don't see a particular benefit in the stricter

XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a

consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that

"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),

I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of

view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation

it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons

(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all

consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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/20110826/edb5c99c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/edb5c99c/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/edb5c99c/attachment-0003.gif>

From ryman at ca.ibm.com  Fri Aug 26 15:58:50 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 15:58:50 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
Message-ID: <OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006DC2EF@ca.ibm.com>

Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you 
include element content. If you use rdf:datatype then only character 
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal" 
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince 
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 03:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just 
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make 
it easy to write literals of this kind"). Either way you write it, you end 
up with the same statement. Two statements with the same subject, the same 
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same 
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with 
some sort of privileged XMLLiteral representation that couldn't written 
out using any other RDF notation.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the 
content a string that looks like XHTML, i.e. the


From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 


http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 


literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 


There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 


suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 


it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 



Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 


convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 


than at the model level), so I believe that one couldn't use it to produce 


or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 


odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 


- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 


datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 


parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 


the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 


preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 


However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 


since it impairs interoperability.

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




Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 


thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 


use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 


of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 


a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 


in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 


XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 


note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 


syntax. And without that, I don't see a particular benefit in the stricter 


XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 


consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 


"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 


I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 


view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 


it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 


(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 


consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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





From ryman at ca.ibm.com  Fri Aug 26 16:13:52 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:13:52 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
	<OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
Message-ID: <OF8CEBFEC5.987439B3-ON852578F8.006E00F0-852578F8.006F2349@ca.ibm.com>

Randy,

I validated the RDF at the W3C Validator. I've also tried it out via 
Fuseki which uses Jena.

As I said, you can have a datatype of XMLLiteral that happens to include 
just a string which may include escaped characters, e.g. " 1 &lt; 2".  For 
it to be XHTML, it should have elements in the XHTML namespace.

 I just checked the Jena wiki [1]. Note the example:

More about Literals and Datatypes
RDF literals are not just simple strings. Literals may have a language tag 
to indicate the language of the literal. The literal "chat" with an 
English language tag is considered different to the literal "chat" with a 
French language tag. This rather strange behaviour is an artefact of the 
original RDF/XML syntax.
Further there are really two sorts of Literals. In one, the string 
component is just that, an ordinary string. In the other the string 
component is expected to be a well balanced fragment of XML. When an RDF 
Model is written as RDF/XML a special construction using a 
parseType='Literal' attribute is used to represent it.
In Jena, these attributes of a literal may be set when the literal is 
constructed, e.g. in tutorial 11:
// create the resource
Resource r = model.createResource();

// add the property
r.addProperty(RDFS.label, model.createLiteral("chat", "en"))
 .addProperty(RDFS.label, model.createLiteral("chat", "fr"))
 .addProperty(RDFS.label, model.createLiteral("<em>chat</em>", true));

// write out the Model
model.write(system.out);
produces
<rdf:RDF
  xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
  xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#'
 >
  <rdf:Description rdf:nodeID="A0">
    <rdfs:label xml:lang='en'>chat</rdfs:label>
    <rdfs:label xml:lang='fr'>chat</rdfs:label>
    <rdfs:label rdf:parseType='Literal'><em>chat</em></rdfs:label>
  </rdf:Description>
</rdf:RDF>


[1] 
http://jena.sourceforge.net/tutorial/RDF_API/#ch-More%20about%20Literals%20and%20Datatypes

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get 
jena to write out the property this way by setting an option on the 
writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when 
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the 
value's type in its serialized form in cases where only one datatype is 
allowed.  It looks like bits of the "schema" get repeated over and over.

-Randy




From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 






From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 

it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 

convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 

than at the model level), so I believe that one couldn't use it to produce 

or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 

odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 

datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 

parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 

preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 

However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 

since it impairs interoperability.

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



Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 

use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 

of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 

a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 

in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 

XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 

note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 

syntax. And without that, I don't see a particular benefit in the stricter 

XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 

consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 

"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 

I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 

view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 

it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 

(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 

consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Fri Aug 26 16:28:54 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:28:54 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
	<OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
Message-ID: <OF6FE7077F.DBDB00DB-ON852578F8.006F1789-852578F8.007083BA@ca.ibm.com>

Randy,

For your second question/comment: 

[Off topic]  I'm not sure I really see the benefit to including the 
value's type in its serialized form in cases where only one datatype is 
allowed.  It looks like bits of the "schema" get repeated over and over.

The reason is that there is no "schema" in the usual OO or database sense. 
An RDF property can have any value and be repeated multiple times with 
different values. In the case of OSLC, we try to say what to expect via 
ResourceShapes, and we could "cast" plain literals to the correct data 
value. However, we expect our RDF to be consumed by other applications and 
so we need to include the datatypes to avoid ambiguity, e.g. is "true" a 
boolean or a string?

I do agree that RDF looks very verbose with all the datatypes.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get 
jena to write out the property this way by setting an option on the 
writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when 
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the 
value's type in its serialized form in cases where only one datatype is 
allowed.  It looks like bits of the "schema" get repeated over and over.

-Randy




From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 






From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 

it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 

convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 

than at the model level), so I believe that one couldn't use it to produce 

or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 

odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 

datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 

parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 

preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 

However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 

since it impairs interoperability.

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



Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 

use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 

of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 

a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 

in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 

XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 

note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 

syntax. And without that, I don't see a particular benefit in the stricter 

XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 

consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 

"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 

I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 

view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 

it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 

(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 

consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From davidms at ca.ibm.com  Fri Aug 26 16:37:55 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 16:37:55 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
Message-ID: <OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@ca.ibm.com>


Hi again Arthur,

Lots of good points to address, so my responses are inline (also note that
I wrote my previous, short reply to your later message in the middle of
writing this longer one, so there may be a bit of overlap).

[Disclaimer: I realize I'm talking a lot about Jena in this message. That's
because it's what I know. If there are other RDF toolkits in use, their
behaviour is certainly relevant, too, and it would be good to hear from
people with knowledge of them.]

Arthur Ryman/Toronto/IBM wrote on 08/25/2011 04:27:40 PM:
>
> 1. XML Namespaces.
>
> The spec doesn't say "for XHTML, you need to insert an xmlns attribute
for
> http://www.w3.org/1999/xhtml" because that is part of the XHTML
> standard, i.e. it's not XHTML unless the elements are in the XHTML
namespace.

I agree that XHTML does mean using the XHTML namespace, but I also believe
it would have been helpful to underline that fact in the OSLC Core spec.
Also, I still can't find a single example in the spec that actually shows
markup in the value of an XMLLiteral-typed literal, which also would have
been helpful. I notice that RTC doesn't use a namespace, so I suppose it
wasn't obvious to them.

> 2. Jena
>
> I loaded the sample RDF/XML  into Fuseki which uses Jena and it
> produced the correct result. I assume the Jena API lets you get an
> XML DOM from the literal value.

Thanks for this! I didn't know this, and it's reassuring. I was able to
replicate this behaviour with pure Jena, simply by loading an RDF/XML
resource containing your input and printing the type and lexical form of
the literal:

Datatype: http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
Lexical form:  12345: <s xmlns="http://www.w3.org/1999/xhtml">Null pointer
exception during startup</s>

Unfortunately, though, your assumption is not correct: Jena provides no
access to underlying DOM. It appears that during parsing it computes the
exclusive canonical form of the XML subset, as the RDF specs prescribe, and
simply records that as the literal's lexical value. But, Jena's built-in
XMLLiteral type support just uses java.lang.String as its value type. I was
surprised when I first discovered that, too, but you can see for yourself
in XMLLiteralType.parse().

> 3.  XHTML versus HTML
>
> The primary reason is that RDF supports XHTML via the XMLLiteral
> datatype. There is no parsing support for HTML built into RDF.

RDF doesn't require parsing support to use other datatypes, at least not in
the abstract sense. Abstractly, a typed literal is just a datatype
(identified by a URI) and a lexical form. Of course, it's very helpful in
an implementation if you can automatically convert that to a more useful
typed value (i.e. an Integer, Boolean, etc.), but that's purely a toolkit
concern. Jena will support any datatype via its BaseDatatype.TypedValue
wrapper type, but it's pluggable, so you can add specific parsing support
for any type you wish.

> Another strong reason is that the syntax of HTML is very irregular
> and hard to parse correctly - that is one of the reasons XML was
> invented. This is very important from a security viewpoint. To guard
> against script injection attacks, you really should parse the input
> and remove any <script> elements or Javascript attributes. Doing
> that correctly for HTML requires a full HTML parser. On the other
> hand, the XHTML is given to you as a DOM which you can easily
> traverse or process using XSLT or XPATH.

But as you said, HTML Tidy can be used to parse HTML. You could even plug
it in to Jena to do the parsing automatically for a defined datatype, which
would be more convenient than the built in XMLLiteral support. Also, I
really think that whether or not you need to parse and cleanse depends upon
what you're doing with the data. It may not be necessary for an OSLC
adapter that's merely passing along data from a trusted source, since it's
incumbent upon a security-conscious client to do that, itself.

> 4. Datatypes
>
> The specs do specify the datatypes for some properties. Look at the
> Value-Type column of the tables, e.g. [1]. You need to include the
> datatype explicitly for ints, dates, XML. etc. You specify that
> using rdf:datatype in RDF/XML, or using ^^ in Turtle.

Sorry if I wasn't clear. What I meant was that specs don't appear to say
whether consumers and producers should use/expect typed literals or plain
literals. I do see that the tables prescribe datatypes for the various
literal-typed properties, but it doesn't say anywhere whether that means
that typed literals should actually be used to specify those types, or that
plain literals should be used (since those prescribed types are already
presumed to be known).

> 5. Inventing new Datatypes
>
> The RDF spec defines the XSD datatypes and the XMLLiteral datatype.
> RDF parsers know how to parse those. If someone introduces a new
> datatype URI, it could break parsers since they won't know how to
> parse the contents. There is no standard way to define new datatypes.
>
> Try it with the RDF Validation service [2]

I had no problem parsing the following RDF/XML document (in which I've used
my own HTML type) with the service:

<rdf:RDF
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:oslc_cm="http://open-services.net/ns/cm#" >
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title
rdf:datatype="http://open-services.net/ns/core/types#HTML">12345:
&lt;s&gt;Null pointer exception during startup&lt;/s&gt;</dcterms:title>
    <rdf:type rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
  </rdf:Description>
</rdf:RDF>


Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/af37fbae/attachment-0001.html>

From hudsonr at us.ibm.com  Fri Aug 26 16:48:13 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Fri, 26 Aug 2011 16:48:13 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006DC2EF@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006DC2EF@ca.ibm.com>
Message-ID: <OF2E1EAFE2.B98E1BAD-ON852578F8.0071D7CE-852578F8.0072473A@us.ibm.com>

Either that validator is completely broken, or RDF/XML doesn't support
strings containing the character "<".

    <dc:title">World Wide Web &lt; Consortium</dc:title>

Jena will both produce and consume the alternate syntax I provided before.

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/26/2011 03:59 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you
include element content. If you use rdf:datatype then only character
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal"
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 03:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make
it easy to write literals of this kind"). Either way you write it, you end
up with the same statement. Two statements with the same subject, the same
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with
some sort of privileged XMLLiteral representation that couldn't written
out using any other RDF notation.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the
content a string that looks like XHTML, i.e. the


From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for


http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the


literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.


There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test


suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,


it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________




Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a


convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other


than at the model level), so I believe that one couldn't use it to produce


or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so


odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties


- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF


datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The


parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose


the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of


preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.


However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged


since it impairs interoperability.

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





Regards,
___________________________________________________________________________




Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this


thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the


use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use


of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use


a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral


in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other


XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And


note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"


syntax. And without that, I don't see a particular benefit in the stricter


XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a


consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that


"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),


I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of


view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation


it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons


(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all


consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________




Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact




[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format






_______________________________________________
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

_______________________________________________
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




_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net




From davidms at ca.ibm.com  Fri Aug 26 16:54:10 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 16:54:10 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
	<OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@LocalDomain>
Message-ID: <OF7C87C9F9.066C4358-ON852578F8.00728620-852578F8.0072D2F4@ca.ibm.com>


Dave Steinberg/Toronto/IBM wrote on 08/26/2011 04:37:55 PM:

> I had no problem parsing the following RDF/XML document (in which
> I've used my own HTML type) with the service:

Oops. I see that the validator is reporting a value with the &lt;s and
&gt;s intact. I believe that must be an error; it's not bothering to
interpret the XML entities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/350dc129/attachment.html>

From ryman at ca.ibm.com  Fri Aug 26 16:58:10 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:58:10 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7C87C9F9.066C4358-ON852578F8.00728620-852578F8.0072D2F4@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>	<OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@LocalDomain>
	<OF7C87C9F9.066C4358-ON852578F8.00728620-852578F8.0072D2F4@ca.ibm.com>
Message-ID: <OF46D3DE46.982C94EE-ON852578F8.007323A0-852578F8.007331C1@ca.ibm.com>

Dave,

I believe it's just escaping them for output.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 04:54 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave Steinberg/Toronto/IBM wrote on 08/26/2011 04:37:55 PM:

> I had no problem parsing the following RDF/XML document (in which 
> I've used my own HTML type) with the service:

Oops. I see that the validator is reporting a value with the &lt;s and 
&gt;s intact. I believe that must be an error; it's not bothering to 
interpret the XML entities._______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From ryman at ca.ibm.com  Fri Aug 26 16:58:10 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:58:10 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
	<OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@ca.ibm.com>
Message-ID: <OFA3FECFEF.ECCAA761-ON852578F8.00724F0D-852578F8.007331BE@ca.ibm.com>

Dave,

It's good to know that the W3C RDF Validator accepted your private 
datatype. However, I haven't seen new datatypes being introduced by other 
vocabularies. If we do that it might reduce interoperablility.

Too bad Jena doesn't give you a DOM. Reparsing doesn't seem too 
inconvenient.

Omitting the datatypes because "we" know what they should be would reduce 
interoperability. We assume other applications will use our RDF resources, 
so we should make them explicit.

I agree the spec could be clearer. I believe Steve is improving it.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 04:39 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi again Arthur,

Lots of good points to address, so my responses are inline (also note that 
I wrote my previous, short reply to your later message in the middle of 
writing this longer one, so there may be a bit of overlap).

[Disclaimer: I realize I'm talking a lot about Jena in this message. 
That's because it's what I know. If there are other RDF toolkits in use, 
their behaviour is certainly relevant, too, and it would be good to hear 
from people with knowledge of them.]

Arthur Ryman/Toronto/IBM wrote on 08/25/2011 04:27:40 PM:
> 
> 1. XML Namespaces. 
> 
> The spec doesn't say "for XHTML, you need to insert an xmlns attribute 
for 
> http://www.w3.org/1999/xhtml" because that is part of the XHTML 
> standard, i.e. it's not XHTML unless the elements are in the XHTML 
namespace. 

I agree that XHTML does mean using the XHTML namespace, but I also believe 
it would have been helpful to underline that fact in the OSLC Core spec. 
Also, I still can't find a single example in the spec that actually shows 
markup in the value of an XMLLiteral-typed literal, which also would have 
been helpful. I notice that RTC doesn't use a namespace, so I suppose it 
wasn't obvious to them.

> 2. Jena
> 
> I loaded the sample RDF/XML  into Fuseki which uses Jena and it 
> produced the correct result. I assume the Jena API lets you get an 
> XML DOM from the literal value.

Thanks for this! I didn't know this, and it's reassuring. I was able to 
replicate this behaviour with pure Jena, simply by loading an RDF/XML 
resource containing your input and printing the type and lexical form of 
the literal:

Datatype: http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
Lexical form:  12345: <s xmlns="http://www.w3.org/1999/xhtml">Null pointer 
exception during startup</s>

Unfortunately, though, your assumption is not correct: Jena provides no 
access to underlying DOM. It appears that during parsing it computes the 
exclusive canonical form of the XML subset, as the RDF specs prescribe, 
and simply records that as the literal's lexical value. But, Jena's 
built-in XMLLiteral type support just uses java.lang.String as its value 
type. I was surprised when I first discovered that, too, but you can see 
for yourself in XMLLiteralType.parse().

> 3.  XHTML versus HTML
> 
> The primary reason is that RDF supports XHTML via the XMLLiteral 
> datatype. There is no parsing support for HTML built into RDF.

RDF doesn't require parsing support to use other datatypes, at least not 
in the abstract sense. Abstractly, a typed literal is just a datatype 
(identified by a URI) and a lexical form. Of course, it's very helpful in 
an implementation if you can automatically convert that to a more useful 
typed value (i.e. an Integer, Boolean, etc.), but that's purely a toolkit 
concern. Jena will support any datatype via its BaseDatatype.TypedValue 
wrapper type, but it's pluggable, so you can add specific parsing support 
for any type you wish.

> Another strong reason is that the syntax of HTML is very irregular 
> and hard to parse correctly - that is one of the reasons XML was 
> invented. This is very important from a security viewpoint. To guard
> against script injection attacks, you really should parse the input 
> and remove any <script> elements or Javascript attributes. Doing 
> that correctly for HTML requires a full HTML parser. On the other 
> hand, the XHTML is given to you as a DOM which you can easily 
> traverse or process using XSLT or XPATH.

But as you said, HTML Tidy can be used to parse HTML. You could even plug 
it in to Jena to do the parsing automatically for a defined datatype, 
which would be more convenient than the built in XMLLiteral support. Also, 
I really think that whether or not you need to parse and cleanse depends 
upon what you're doing with the data. It may not be necessary for an OSLC 
adapter that's merely passing along data from a trusted source, since it's 
incumbent upon a security-conscious client to do that, itself.

> 4. Datatypes
> 
> The specs do specify the datatypes for some properties. Look at the 
> Value-Type column of the tables, e.g. [1]. You need to include the 
> datatype explicitly for ints, dates, XML. etc. You specify that 
> using rdf:datatype in RDF/XML, or using ^^ in Turtle. 

Sorry if I wasn't clear. What I meant was that specs don't appear to say 
whether consumers and producers should use/expect typed literals or plain 
literals. I do see that the tables prescribe datatypes for the various 
literal-typed properties, but it doesn't say anywhere whether that means 
that typed literals should actually be used to specify those types, or 
that plain literals should be used (since those prescribed types are 
already presumed to be known).

> 5. Inventing new Datatypes
> 
> The RDF spec defines the XSD datatypes and the XMLLiteral datatype. 
> RDF parsers know how to parse those. If someone introduces a new 
> datatype URI, it could break parsers since they won't know how to 
> parse the contents. There is no standard way to define new datatypes. 
> 
> Try it with the RDF Validation service [2]

I had no problem parsing the following RDF/XML document (in which I've 
used my own HTML type) with the service:

<rdf:RDF
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:oslc_cm="http://open-services.net/ns/cm#" > 
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title rdf:datatype="
http://open-services.net/ns/core/types#HTML">12345: &lt;s&gt;Null pointer 
exception during startup&lt;/s&gt;</dcterms:title>
    <rdf:type rdf:resource="http://open-services.net/ns/cm#ChangeRequest
"/>
  </rdf:Description>
</rdf:RDF>


Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From davidms at ca.ibm.com  Fri Aug 26 17:31:11 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 17:31:11 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
Message-ID: <OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>


Hi Arthur,

Sorry, but I just don't agree. The two links you gave are both to the
RDF/XML spec, and they describe a special syntax for XMLLiteral-typed
literals and a general syntax for typed literals. They do not state that
the general syntax cannot be used for the case of XMLLiteral, and they
don't say anything that contradicts my understanding of the RDF abstract
data model.

Indeed, if you follow the "XML literals" link in Section 2.8, the RDF
Concepts spec defines XMLLiteral, like any other datatype, with a lexical
space, a value space and a mapping between the two. So, given any XML
value, what is to prevent you from using that mapping to compute a
corresponding lexical form, combining it with the datatype URI, and using
the ordinary literal notation (in any RDF concrete syntax)?

I just tried entering the following two RDF/XML documents into the
validation service:

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title rdf:parseType="Literal"
xmlns="http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception
during startup</s></dcterms:title>
  </rdf:Description>
</rdf:RDF>

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title
rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
12345: &lt;s xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception
during startup&lt;/s&gt;</dcterms:title>
  </rdf:Description>
</rdf:RDF>

It yielded exactly the same result in both cases:



I can also confirm Steve's claim that Jena can be configured to write out
exactly the same triples using either syntax.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                                                                
  From:       Arthur Ryman/Toronto/IBM                                                                                                          
                                                                                                                                                
  To:         Dave Steinberg/Toronto/IBM at IBMCA                                                                                                  
                                                                                                                                                
  Cc:         oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                  
                                                                                                                                                
  Date:       08/26/2011 03:58 PM                                                                                                               
                                                                                                                                                
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                                                   
                                                                                                                                                




Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you
include element content. If you use rdf:datatype then only character
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal"
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________
                                                                              
 Arthur Ryman                                                                 
                                                                              
 DE, PPM & Reporting Chief Architect                                          
                                                                              
 IBM Software, Rational                                                       
                                                                              
 Toronto Lab | +1-905-413-3077 (office) |                                     
 +1-416-939-5063 (mobile)                                                     
                                                                              





                                                                                                                                                
  From:       Dave Steinberg/Toronto/IBM at IBMCA                                                                                                  
                                                                                                                                                
  To:         oslc-core at open-services.net                                                                                                       
                                                                                                                                                
  Date:       08/26/2011 03:22 PM                                                                                                               
                                                                                                                                                
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                                                   
                                                                                                                                                
  Sent by:    oslc-core-bounces at open-services.net                                                                                               
                                                                                                                                                





Arthur,

I believe you're mistaken. I think that parseType="Literal" is just
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make
it easy to write literals of this kind"). Either way you write it, you end
up with the same statement. Two statements with the same subject, the same
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with
some sort of privileged XMLLiteral representation that couldn't written out
using any other RDF notation.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Inactive hide details for Arthur Ryman---08/26/2011 02:22:29 PM---Randy,
Your example makes the content a string that looks likArthur
Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the content a
string that looks like XHTML, i.e. the
                                                                           
                                                                           
 From:      Arthur Ryman/Toronto/IBM                                       
                                                                           
                                                                           
 To:        Randy Hudson/Raleigh/IBM at IBMUS                                 
                                                                           
                                                                           
 Cc:        Dave Steinberg <davidms at ca.ibm.com>,                           
            oslc-core at open-services.net,                                   
            oslc-core-bounces at open-services.net                            
                                                                           
                                                                           
 Date:      08/26/2011 02:22 PM                                            
                                                                           
                                                                           
 Subject:   Re: [oslc-core] OSLC Compact representation, titles with       
            markup                                                         
                                                                           





Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,

it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a

convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other

than at the model level), so I believe that one couldn't use it to produce

or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so

odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF

datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The

parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of

preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.

However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged

since it impairs interoperability.

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




Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the

use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use

of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use

a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral

in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other

XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And

note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"

syntax. And without that, I don't see a particular benefit in the stricter

XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a

consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that

"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),

I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of

view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation

it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons

(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all

consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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/20110826/ff138409/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12375707.gif
Type: image/gif
Size: 9285 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12992179.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0007.gif>

From davidms at ca.ibm.com  Fri Aug 26 17:35:00 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 17:35:00 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
Message-ID: <OFD7B386AA.44702968-ON852578F8.007682D9-852578F8.0076901F@ca.ibm.com>

> I can also confirm Steve's claim that Jena can be configured to
> write out exactly the same triples using either syntax.

Apologies: Randy's claim.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/945dd6af/attachment.html>

From davidms at ca.ibm.com  Fri Aug 26 19:50:29 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 19:50:29 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF6FE7077F.DBDB00DB-ON852578F8.006F1789-852578F8.007083BA@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
	<OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
	<OF6FE7077F.DBDB00DB-ON852578F8.006F1789-852578F8.007083BA@LocalDomain>
Message-ID: <OFB3D589A2.890AE53F-ON852578F8.0081463F-852578F8.0082F769@ca.ibm.com>


Hi all,

I totally agree with Arthur on this. I think typed literals are a valuable
feature of RDF, and well worth using. As Arthur says, they allow a consumer
to make more sense of a literal value without already having a schema or
resource shape. Moreover, they allow you to use the same properties with
different types in a single resource. This is actually directly applicable
to the issue at hand with XHTML in compact rendering. Instead of defining
additional properties likes oslc:htmlEncodedTitle, we could define an HTML
type and use it as follows:

<rdf:RDF
    xmlns:oslc_types="http://open-services.net/ns/core/types#"
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title
rdf:datatype="http://open-services.net/ns/core/types#HTML">12345:
&lt;s&gt;Null pointer exception during startup&lt;/s&gt;</dcterms:title>
    <dcterms:title rdf:parseType="Literal">12345: <s
xmlns="http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>
  </rdf:Description>
</rdf:RDF>

This seems the more natural RDF approach to me, and you only need to define
one new type, which you could use with any number of properties.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                             
  From:       Arthur Ryman/Toronto/IBM                                                                       
                                                                                                             
  To:         Randy Hudson/Raleigh/IBM at IBMUS                                                                 
                                                                                                             
  Cc:         Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,                              
              oslc-core-bounces at open-services.net                                                            
                                                                                                             
  Date:       08/26/2011 04:28 PM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             





Randy,

For your second question/comment:

[Off topic]  I'm not sure I really see the benefit to including the
value's type in its serialized form in cases where only one datatype is
allowed.  It looks like bits of the "schema" get repeated over and over.

The reason is that there is no "schema" in the usual OO or database sense.
An RDF property can have any value and be repeated multiple times with
different values. In the case of OSLC, we try to say what to expect via
ResourceShapes, and we could "cast" plain literals to the correct data
value. However, we expect our RDF to be consumed by other applications and
so we need to include the datatypes to avoid ambiguity, e.g. is "true" a
boolean or a string?

I do agree that RDF looks very verbose with all the datatypes.

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get
jena to write out the property this way by setting an option on the
writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the
value's type in its serialized form in cases where only one datatype is
allowed.  It looks like bits of the "schema" get repeated over and over.

-Randy




From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)






From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,

it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a

convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other

than at the model level), so I believe that one couldn't use it to produce

or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so

odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF

datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The

parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of

preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.

However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged

since it impairs interoperability.

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




Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the

use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use

of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use

a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral

in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other

XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And

note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"

syntax. And without that, I don't see a particular benefit in the stricter

XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a

consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that

"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),

I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of

view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation

it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons

(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all

consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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/20110826/3a46fedf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/3a46fedf/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/3a46fedf/attachment-0003.gif>

From sspeiche at us.ibm.com  Tue Aug 30 11:50:07 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 30 Aug 2011 11:50:07 -0400
Subject: [oslc-core] REMINDER: OSLC Core WG Meeting Day/Time Survey --
 Please Respond by Sept 1st
Message-ID: <OF5756EEFA.5CE220DA-ON852578FC.0056DC17-852578FC.0056FCA3@us.ibm.com>

If you have not done so, please fill out the survey.  I'm still expecting 
feedback from some people that I haven't seen.

Survey link: http://doodle.com/n5bef5gepvx2fhaw

Using dates 2 weeks from now just as an example.  Pick a day/time of week 
that works, even if it doesn't work for this one week.

Let me know if there are any questions.

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



From ryman at ca.ibm.com  Tue Aug 30 17:45:26 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 30 Aug 2011 17:45:26 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
Message-ID: <OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>

Dave,

My point was that when you use rdf:datatype, the content of the element 
must be a string, not XML. When you use rdf:parseType="Literal" the 
content is expected to be XML. In the RDF data model, the lexical space of 
XML consists of well-formed XML fragments, i.e. there is no escaping other 
than that required by XML.

You managed to get the rdf:datatype case to validate by escaping the XML 
markup, i.e. turning it into a string, which seems like unnecessary work 
if you already have an XML fragment.

BTW, I don't understand why the W3C RDF Validation service is displaying 
the XML content as escaped. That means the data is actually 
double-escaped. I'd be happier seeing plain text  N-Triples or Turtle.

It seems to me that since RDF/XML is well-formed XML, then the natural way 
to include XML literals is as XML, not as a string that contains escaped 
XML markup. However, I concede your point that in principle we don't need 
rdf:parseType="Literal"  if you are sure that we get exactly the same set 
of triples using just rdf:datatype. If so, you are correct in saying that 
rdf:parseType="Literal" is just syntactic sugar.

I see where you are going with this. You want OSLC to create a new 
datatype for HTML and you are demonstrating that rdf:datatype gives you 
the mechanism to do this. As I said before, creating a new datatype will 
limit interoperability since other processors will not know how to process 
the new datatype. There is no standard way to define the meaning of a new 
RDF datatype.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 05:31 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Sorry, but I just don't agree. The two links you gave are both to the 
RDF/XML spec, and they describe a special syntax for XMLLiteral-typed 
literals and a general syntax for typed literals. They do not state that 
the general syntax cannot be used for the case of XMLLiteral, and they 
don't say anything that contradicts my understanding of the RDF abstract 
data model.

Indeed, if you follow the "XML literals" link in Section 2.8, the RDF 
Concepts spec defines XMLLiteral, like any other datatype, with a lexical 
space, a value space and a mapping between the two. So, given any XML 
value, what is to prevent you from using that mapping to compute a 
corresponding lexical form, combining it with the datatype URI, and using 
the ordinary literal notation (in any RDF concrete syntax)?

I just tried entering the following two RDF/XML documents into the 
validation service:

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml
"> 12345: <s>Null pointer exception during startup</s></dcterms:title>
</rdf:Description>
</rdf:RDF>

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>
</rdf:Description>
</rdf:RDF>

It yielded exactly the same result in both cases:



I can also confirm Steve's claim that Jena can be configured to write out 
exactly the same triples using either syntax.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 03:58:51 PM---Dave, No, it's not just syntactic 
sugar. You need rdf:parseType="Literal" if you include element con


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/26/2011 03:58 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you 
include element content. If you use rdf:datatype then only character 
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal" 
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince 
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 


Dave Steinberg---08/26/2011 03:22:10 PM---Arthur, I believe you're 
mistaken. I think that parseType="Literal" is just


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/26/2011 03:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just 
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make 
it easy to write literals of this kind"). Either way you write it, you end 
up with the same statement. Two statements with the same subject, the same 
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same 
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with 
some sort of privileged XMLLiteral representation that couldn't written 
out using any other RDF notation.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the 
content a string that looks like XHTML, i.e. the

From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 


http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 


literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 


There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 


suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 


it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 



Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 


convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 


than at the model level), so I believe that one couldn't use it to produce 


or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 


odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 


- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 


datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 


parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 


the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 


preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 


However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 


since it impairs interoperability.

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




Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 


thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 


use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 


of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 


a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 


in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 


XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 


note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 


syntax. And without that, I don't see a particular benefit in the stricter 


XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 


consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 


"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 


I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 


view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 


it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 


(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 


consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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.n et/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





From sspeiche at us.ibm.com  Tue Aug 30 20:33:01 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 30 Aug 2011 20:33:01 -0400
Subject: [oslc-core] Fw: [oslc] New URL for OSLC Community Website
Message-ID: <OFB3F74D8C.C0547CD6-ON852578FD.0002F1D1-852578FD.00030641@us.ibm.com>

FYI for those who are not subscribed to the community list.  I recommend 
you weigh in on Core mail list with any spec issues/concerns.

> From: Steve K Speicher/Raleigh/IBM at IBMUS
> To: Kartik Kanakasabesan/Durham/IBM at IBMUS, 
> Cc: community at open-services.net
> Date: 08/30/2011 08:27 PM
> Subject: Re: [oslc] New URL for OSLC Community Website
> Sent by: community-bounces at open-services.net
> 
> +1
> 
> I think this is a good idea.  It has always been awkward to say "the 
OSLC 
> website" and then say "go to open-services.net", they don't exactly 
match 
> each other.  Looking at available domains (not oslc.net, oslc.org, 
> oslc.com) I saw oslc.co being available.  So I think it makes much 
easier 
> to direct people (without having to buy a domain from someone), to "the 
> OSLC website".
> 
> Regarding migration, I think Kartik has pointed out the 
open-services.net 
> is not going away.  The domain names defined in OSLC specs are not 
> changing.  Though, if accepted we could consider using the shorter "
> http://oslc.co" for the spec namespace base for further specs.
> 
> The redirect is active already, so you can go to http://oslc.co
> 
> Thanks,
> Steve Speicher | IBM Rational Software | (919) 254-0645
> 
> > From: Kartik Kanakasabesan/Durham/IBM at IBMUS
> > To: community at open-services.net, 
> > Date: 08/30/2011 02:45 PM
> > Subject: [oslc] New URL for OSLC Community Website
> > Sent by: community-bounces at open-services.net
> > 
> > Hi Folks, 
> >             Wanted to get feedback from the community on this issue. 
We 
> > would like to propose a new URL for the OSLC website, the proposed URL 

> is 
> > OSLC.co  instead of open-services.net. 
> > the .co domain name stands for community and falls in line with effort 

> we 
> > are pushing forward with OSLC. 
> > I would appreciate any thoughts/cocerns/comment on the matter. 
> > We would like to implement this domain change only if the community 
> agree's with it. 
> > Regards, 
> > Kartik _______________________________________________
> > Community mailing list
> > Community at open-services.net
> > http://open-services.net/mailman/listinfo/community_open-services.net
> 
> 
> _______________________________________________
> Community mailing list
> Community at open-services.net
> http://open-services.net/mailman/listinfo/community_open-services.net
> 



From ryman at ca.ibm.com  Wed Aug 31 09:17:38 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Wed, 31 Aug 2011 09:17:38 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
	<OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>
Message-ID: <OF4339B386.01E399CB-ON852578FD.0045DC2C-852578FD.0049075A@ca.ibm.com>

Dave/Randy,

Thx for persisting on this point. It turns out that the W3C RDF Validator 
is in fact displaying markup characters in strings wrong. It is escaping 
them. You can see the correct, unescaped, results by turning on the 
Advanced option of N-Triples output.

This discussion has made me realize that my suggested name for a new 
oslc:htmlEncodedTitle property is misleading. Encoding is only required 
when you put the triple in an XML document., e.g. the OSLC compact 
rendering resource  The encoding is removed by the parser and you end up 
with the unescaped string. Since we are defining RDF predicates, the 
reference to encoding is inappropriate because there is no encoding at the 
RDF value level.

We therefore have the following alternatives for markup in the title:

1. Use XML Literal datatype and XHTML content.
2. Define a new datatype for HTML
3. Define a new predicate for HTML titles, e.g. oslc:htmlTitle

Using HTML within the context of the UI preview is OK since the UI is 
expected to be a web UI and you'd just copy the string.

However, I think using HTML in RDF is not a good idea because all readers 
of the data would then have to cope with it, I mentioned that Tidy could 
be used by the writer of the data to convert it to XHTML. That does not 
mean this is practical for all readers of the data. In general, when you 
are designing a format for interoperability, you should convert diverse 
formats into one common format. We should therefore adopt XHTML as the one 
common format for marked up text interchange.

Recall that HTML is only one alternate format. We also have sources that 
produce rich text (RTF), and wiki text. Agreeing on XHTML is a useful 
simplification.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Dave Steinberg/Toronto/IBM at IBMCA
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/30/2011 05:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

My point was that when you use rdf:datatype, the content of the element 
must be a string, not XML. When you use rdf:parseType="Literal" the 
content is expected to be XML. In the RDF data model, the lexical space of 

XML consists of well-formed XML fragments, i.e. there is no escaping other 

than that required by XML.

You managed to get the rdf:datatype case to validate by escaping the XML 
markup, i.e. turning it into a string, which seems like unnecessary work 
if you already have an XML fragment.

BTW, I don't understand why the W3C RDF Validation service is displaying 
the XML content as escaped. That means the data is actually 
double-escaped. I'd be happier seeing plain text  N-Triples or Turtle.

It seems to me that since RDF/XML is well-formed XML, then the natural way 

to include XML literals is as XML, not as a string that contains escaped 
XML markup. However, I concede your point that in principle we don't need 
rdf:parseType="Literal"  if you are sure that we get exactly the same set 
of triples using just rdf:datatype. If so, you are correct in saying that 
rdf:parseType="Literal" is just syntactic sugar.

I see where you are going with this. You want OSLC to create a new 
datatype for HTML and you are demonstrating that rdf:datatype gives you 
the mechanism to do this. As I said before, creating a new datatype will 
limit interoperability since other processors will not know how to process 

the new datatype. There is no standard way to define the meaning of a new 
RDF datatype.

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 05:31 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Sorry, but I just don't agree. The two links you gave are both to the 
RDF/XML spec, and they describe a special syntax for XMLLiteral-typed 
literals and a general syntax for typed literals. They do not state that 
the general syntax cannot be used for the case of XMLLiteral, and they 
don't say anything that contradicts my understanding of the RDF abstract 
data model.

Indeed, if you follow the "XML literals" link in Section 2.8, the RDF 
Concepts spec defines XMLLiteral, like any other datatype, with a lexical 
space, a value space and a mapping between the two. So, given any XML 
value, what is to prevent you from using that mapping to compute a 
corresponding lexical form, combining it with the datatype URI, and using 
the ordinary literal notation (in any RDF concrete syntax)?

I just tried entering the following two RDF/XML documents into the 
validation service:

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml
"> 12345: <s>Null pointer exception during startup</s></dcterms:title>
</rdf:Description>
</rdf:RDF>

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>
</rdf:Description>
</rdf:RDF>

It yielded exactly the same result in both cases:



I can also confirm Steve's claim that Jena can be configured to write out 
exactly the same triples using either syntax.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 03:58:51 PM---Dave, No, it's not just syntactic 
sugar. You need rdf:parseType="Literal" if you include element con


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/26/2011 03:58 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you 

include element content. If you use rdf:datatype then only character 
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal" 
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince 
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 


Dave Steinberg---08/26/2011 03:22:10 PM---Arthur, I believe you're 
mistaken. I think that parseType="Literal" is just


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/26/2011 03:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just 
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make 
it easy to write literals of this kind"). Either way you write it, you end 

up with the same statement. Two statements with the same subject, the same 

predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same 
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with 
some sort of privileged XMLLiteral representation that couldn't written 
out using any other RDF notation.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the 
content a string that looks like XHTML, i.e. the

From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 



Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 



http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 



literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 



There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 



suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 



it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 




Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 



convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 



than at the model level), so I believe that one couldn't use it to produce 



or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 



odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 



- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 



datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 



parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 



the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 



preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 



However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 



since it impairs interoperability.

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





Regards, 
___________________________________________________________________________ 




Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 



thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 



use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 



of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 



a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 



in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 



XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 



note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 



syntax. And without that, I don't see a particular benefit in the stricter 



XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 



consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 



"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 



I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 



view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 



it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 



(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 



consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 




Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact




[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format






_______________________________________________
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

_______________________________________________
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




_______________________________________________
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.n et/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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From ryman at ca.ibm.com  Wed Aug 31 11:03:06 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Wed, 31 Aug 2011 11:03:06 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF4339B386.01E399CB-ON852578FD.0045DC2C-852578FD.0047AE42@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
	<OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>
	<OF4339B386.01E399CB-ON852578FD.0045DC2C-852578FD.0047AE42@LocalDomain>
Message-ID: <OF78BCA281.77E9C908-ON852578FD.005090E8-852578FD.0052AEFA@ca.ibm.com>

Dave/Randy,

I was wrong in saying that rdf:parseType="Literal" was required. I 
verified your statement that rdf:parseType="Literal" is syntactic sugar 
for a corresponding rdf:datatype attribute by using the jena.rdfcopy 
utility which converts RDF/XML to N-TRIPLE. The W3C RDF Validation service 
was erroneously escaping markup on output. The escaping is just an 
artifact of XML and is not part of the lexical space of RDF literal 
values. I am including an RDF/XML document and its N-TRIPLE equivalent.

Note that subjects 3 and 4 have identical objects.

RDF/XML

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dcterms="http://purl.org/dc/terms/">

<rdf:Description rdf:about="http://example.com/subject/1">
   <dcterms:title>1 &lt; 2</dcterms:title>
</rdf:Description>

<rdf:Description rdf:about="http://example.com/subject/2">
   <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml">This is 
<s>strikethrough</s>.</dcterms:title>
</rdf:Description>

<rdf:Description rdf:about="http://example.com/subject/3">
   <dcterms:title rdf:parseType="Literal">This is 
<s>strikethrough</s>.</dcterms:title>
</rdf:Description>

<rdf:Description rdf:about="http://example.com/subject/4">
   <dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">This is 
&lt;s&gt;strikethrough&lt;/s&gt;.</dcterms:title>
</rdf:Description>

</rdf:RDF>

N-TRIPLE

<http://example.com/subject/1> <http://purl.org/dc/terms/title> "1 < 2" .
<http://example.com/subject/2> <http://purl.org/dc/terms/title> "This is 
<s xmlns=\"http://www.w3.org/1999/xhtml\">strikethrough</s>."^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .
<http://example.com/subject/3> <http://purl.org/dc/terms/title> "This is 
<s>strikethrough</s>."^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .
<http://example.com/subject/4> <http://purl.org/dc/terms/title> "This is 
<s>strikethrough</s>."^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 



Arthur Ryman/Toronto/IBM wrote on 08/31/2011 09:02:56 AM:

> [image removed] 
> 
> Re: [oslc-core] OSLC Compact representation, titles with markup 
> 
> Arthur Ryman 
> 
> to:
> 
> Dave Steinberg
> 
> 08/31/2011 09:02 AM
> 
> Cc:
> 
> oslc-core, oslc-core-bounces
> 
> Dave/Randy,
> 
> Thx for persisting on this point. It turns out that the W3C RDF 
> Validator is in fact displaying markup characters in strings wrong. 
> It is escaping them. You can see the correct, unescaped, results by 
> turning on the Advanced option of N-Triples output.
> 



From spadgett at us.ibm.com  Sun Aug  7 13:00:51 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Sun, 7 Aug 2011 13:00:51 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
Message-ID: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>


I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact
[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




From spadgett at us.ibm.com  Sun Aug  7 13:06:11 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Sun, 7 Aug 2011 13:06:11 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
Message-ID: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@us.ibm.com>


Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact
[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




From hudsonr at us.ibm.com  Mon Aug  8 11:41:54 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Mon, 8 Aug 2011 11:41:54 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
Message-ID: <OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>

Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett/Durham/IBM                                                                                                                         |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net <oslc-core at open-services.net>                                                                                         |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA                                                                                     |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:06 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSLC Compact representation, titles with markup                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact
[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




From johnarwe at us.ibm.com  Fri Aug 12 07:42:41 2011
From: johnarwe at us.ibm.com (John Arwe)
Date: Fri, 12 Aug 2011 07:42:41 -0400
Subject: [oslc-core] JSON representation rules - typo
Message-ID: <OFC62D3251.D54117F2-ON852578EA.004000CA-852578EA.00405726@us.ibm.com>

http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_JSON 
says, in part:

1.0 For each property of a resource 
1.1 Add field to the resource's JSON object with name set to Prefixed Name 
of property 
1.1.1 If the property is specified as a single-valued property, then make 
field's value literal or JSON Object 
1.1.2 If the property is specified as a multi-valued property, then make 
field's value JSON Array 
1.2 Else if value-type is Literal 
1.2.1 Set field's value to string representation of property value 

Note the "Else if" at 1.2 without a matching "If".  Odds are it should 
read "1.2 If value-type", i.e. just remove the initial Else.


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/20110812/a0b504ca/attachment-0002.html>

From johnarwe at us.ibm.com  Fri Aug 12 09:47:31 2011
From: johnarwe at us.ibm.com (John Arwe)
Date: Fri, 12 Aug 2011 09:47:31 -0400
Subject: [oslc-core] Core 2.0 JSON Representation Guidelines - ambiguity in
 serialization of literals
Message-ID: <OF9958F3AB.828C0E72-ON852578EA.0045748F-852578EA.004BC51F@us.ibm.com>

At [1], under the rules to serialize each property, the prescription for 
Literal is to set the field's value equal to the "string representation" 
of the property value (pasted excerpt below, after [1]).  People are 
asking me if this means (for a value like 1.0 say in a property whose 
value-type is float), if that means 1.0 or "1.0".  Their interpretation of 
[1] is that "1.0" is the required output, implying that its JSON-type must 
be string; if the quotes were omitted, its JSON-type would be number, as I 
read [7].
In looking at the related examples and information about existing 
implementations (various flavors of "follow your nose" through the specs), 
I cannot answer this unambiguously using only the specs I have examined. 
Implementation samples suggest that the quotes are not required.  Here is 
a log of my travels; details for each are below.
[2] OSLC Core Specification:JSON Representation Examples appears to show 
only string and dateTime literals.  Since JSON does not have a native 
dateTime type, that document appears to be silent on this question. 
Recommendation: across the examples, cover each of the value-type 
possibilities.
[3] Open Services for Lifecycle Collaboration Core Specification Version 
2.0 Appendix A: Common Properties ; oslc:ResourceShape Resource lists 
(after the table) the valid value-type values, which includes 
integer/double and friends.  But no examples (they're in [2] in theory, 
fair enough if that were true).  Hmm.
[4] Wander over to CM examples; change requests at least have some 
booleans and dates, let's see how those are serialized in JSON as an 
indicator at least.  No such example.
[5] Remembering that CM defines a shape, and from [3] that shapes can have 
an integer maxsize and a boolean or two, try looking at the CM Shape. Only 
shown as an XML serialization :-(
[6] Having recently found out about the existence of a really good 
jazz.net article on RTC 3's CM usage, comb through that looking for what 
it tells me.  While this is not a guarantee of the spec's intent, it at 
least tells me what one implementation does, and since this implementation 
was one of those involved in spec convergence, it's a better-than-random, 
if not deterministic, example.  Pay-dirt at last, in Example 6 where it 
shows the serialization of oslc:responseInfo that includes 
"oslc:totalCount": 7, ...i.e., no quotes.
[6] Reading down further, I see "dc:identifier": 73, in Appendix B.  I'm 
"sure" identifier is a string, so why not "73"?  Checking in [3], indeed 
the value type of identifier is "string".  Now I'm really confused, or 
there is a bug in the article and/or the implementation from which the 
article was sourced.
[6] Futher down in Appendix B,  "rtc_cm:archived": false, which is 
consistent with totalCount (if the underlying intent is to use the JSON 
built-in types to the degree they match the value-type) but not with 
identifier.
[6] Yet further down, I find    "rtc_cm:correctedEstimate": null,   ... 
suggesting there may be yet another ambiguity in the serialization rules. 
I'm not sure what rule gets me to null, if all properties in RDF are 
optional.
Wander over to the QM spec [8] and its examples [9] + shapes [10].  Mostly 
strings, resources, and few dateTimes.  All the samples+shapes are XML.
Wander over to [11] Reqts Mgmt (since I thought that was implemented), but 
1.0 spec and wg page make me wonder.  Don't find any samples/shapes.
Am I missing something that explains why each of the examples above is 
either definitely right or definitely wrong, and similarly prescriptive 
information for all other value-types?



[1] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_JSON
These are the property rules referred to above. For each property: 
1.0 For each property of a resource 
1.1 Add field to the resource's JSON object with name set to Prefixed Name 
of property 
1.1.1 If the property is specified as a single-valued property, then make 
field's value literal or JSON Object 
1.1.2 If the property is specified as a multi-valued property, then make 
field's value JSON Array 
1.2 Else if value-type is Literal 
1.2.1 Set field's value to string representation of property value 
1.3 Else if value-type is Resource with representation of Reference
[2] http://open-services.net/bin/view/Main/OSLCCoreSpecJSONExamples
[3] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;table=up#oslc_ResourceShape_Resource
[4] http://open-services.net/bin/view/Main/CmSpecificationV2Samples
[5] http://open-services.net/bin/view/Main/CmSpecificationV2Shapes
[6] https://jazz.net/wiki/bin/view/Main/WorkItemAPIsForOSLCCM20
[7] http://tools.ietf.org/html/rfc4627
[8] http://open-services.net/bin/view/Main/QmSpecificationV2
[9] http://open-services.net/bin/view/Main/QmSpecificationV2Samples
[10] http://open-services.net/bin/view/Main/QmSpecificationV2Shapes
[11] http://open-services.net/bin/view/Main/RmHome

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/20110812/30fa7198/attachment-0002.html>

From nally at us.ibm.com  Fri Aug 12 12:04:32 2011
From: nally at us.ibm.com (Martin Nally)
Date: Fri, 12 Aug 2011 10:04:32 -0600
Subject: [oslc-core] AUTO: Martin Nally/Raleigh/IBM is out of the office
 until 06/26/2000. (returning 08/22/2011)
Message-ID: <OF216EF641.205C8B2E-ON872578EA.00584E8E-872578EA.00584E8E@us.ibm.com>


I am out of the office until 08/22/2011.

For urgent CTO office issues, contact Michelle Swenson who will determine
the best option


Note: This is an automated response to your message  "Oslc-Core Digest, Vol
19, Issue 2" sent on 8/12/2011 10:00:10.

This is the only notification you will receive while this person is away.




From aggarwav at us.ibm.com  Fri Aug 12 16:15:10 2011
From: aggarwav at us.ibm.com (Vijay Aggarwal)
Date: Fri, 12 Aug 2011 16:15:10 -0400
Subject: [oslc-core] AUTO: Vijay Aggarwal/Austin/IBM is on vacation
	(returning 08/17/2011)
Message-ID: <OF369C28C8.BF60AFA7-ON852578EA.006F40A4-852578EA.006F40A5@us.ibm.com>


I am out of the office until 08/17/2011.

I will be on vacation until August 17.  Please contact Chris Doan for
Service Desk topics, Daniel Wiegand for Service Catalog topics and James
Matlock for WellPoint topics.  For customer engagements, please contact Bob
Dunyak.

Thanks.
Vijay


Note: This is an automated response to your message  "Oslc-Core Digest, Vol
19, Issue 2" sent on 08/12/2011 12:00:10.

This is the only notification you will receive while this person is away.




From sspeiche at us.ibm.com  Mon Aug 22 10:14:06 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Mon, 22 Aug 2011 10:14:06 -0400
Subject: [oslc-core] JSON representation rules - typo
In-Reply-To: <OFC62D3251.D54117F2-ON852578EA.004000CA-852578EA.00405726@us.ibm.com>
References: <OFC62D3251.D54117F2-ON852578EA.004000CA-852578EA.00405726@us.ibm.com>
Message-ID: <OF6FBE34F4.2C77D0ED-ON852578F4.004E2444-852578F4.004E31FA@us.ibm.com>

Thanks John, I made the fix

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

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 08/12/2011 09:24 AM
> Subject: [oslc-core] JSON representation rules - typo
> Sent by: oslc-core-bounces at open-services.net
> 
> 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?

> sortcol=table;up=#Guidelines_for_JSON says, in part: 
> 
> 1.0 For each property of a resource 
> 1.1 Add field to the resource's JSON object with name set to Prefixed 
Name 
> of property 
> 1.1.1 If the property is specified as a single-valued property, then 
make 
> field's value literal or JSON Object 
> 1.1.2 If the property is specified as a multi-valued property, then make 

> field's value JSON Array 
> 1.2 Else if value-type is Literal 
> 1.2.1 Set field's value to string representation of property value 
> Note the "Else if" at 1.2 without a matching "If".  Odds are it should 
read 
> "1.2 If value-type", i.e. just remove the initial Else. 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net




From ryman at ca.ibm.com  Mon Aug 22 16:10:19 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Mon, 22 Aug 2011 16:10:19 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@us.ibm.com>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@us.ibm.com>
Message-ID: <OFFB796645.6E9BAC4D-ON852578F4.006C9480-852578F4.006E7512@ca.ibm.com>

Sam,

You are correct. If you need to include formatting markup in text, the you 
should use the XML Literal datatype and put XHTML in it. XML Literal 
allows any well-formed  XML fragment, e.g. anything that is valid XML 
element content.

Your example is almost correct. It should also include the XHTML namespace 
declaration. A processor could assume that tags in the default namespace 
are XHTML. However, you should be explicit and include the namespace 
declaration:

  <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml ">12345: <s>Null pointer exception
during startup</s></dcterms:title>


A looked at the core spec [1] for dcterms:title and noticed another typo. 
The description description says:


Title of the resource represented as rich text in XHTML content. SHOULD 
include only content that is valid inside an XHTML <div> element. 

I think this was just copied from the description for dcterms:description, 
which SHOULD be like a <div>. A dcterms:title SHOULD be like a <span>, 
i.e.:

Title of the resource represented as rich text in XHTML content. SHOULD 
include only content that is valid inside an XHTML <span> element. 

[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:07 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Mon Aug 22 16:40:25 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Mon, 22 Aug 2011 16:40:25 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
Message-ID: <OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>

Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Mon Aug 22 16:55:36 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Mon, 22 Aug 2011 16:55:36 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
	<OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
Message-ID: <OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>

Randy,

I think example [3] is wrong. If the datatype is plain text then you 
should not assume it contains encoded HTML. If you need to include markup 
then you should use XML Literal datatype, and use XHTML content. This is 
described in the core spec [4] which gives guidance for putting markup in 
dcterms:title and dcterms:description.

[4] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Randy Hudson <hudsonr at us.ibm.com>
To:
Samuel Padgett <spadgett at us.ibm.com>, Steve K Speicher 
<sspeiche at us.ibm.com>
Cc:
Adam Archer/Toronto/IBM at IBMCA, "oslc-core at open-services.net" 
<oslc-core at open-services.net>
Date:
08/08/2011 11:54 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be 
wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett/Durham/IBM                              |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net <oslc-core at open-services.net>            |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA           
                   |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:06 PM                        |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSLC Compact representation, titles with markup         |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From agarcher at ca.ibm.com  Mon Aug 22 17:00:05 2011
From: agarcher at ca.ibm.com (Adam Archer)
Date: Mon, 22 Aug 2011 17:00:05 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
Message-ID: <OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>

The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at).

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From:   Arthur Ryman/Toronto/IBM
To:     Samuel Padgett <spadgett at us.ibm.com>
Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110822/2dae579d/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110822/2dae579d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110822/2dae579d/attachment-0001.gif>

From davidms at ca.ibm.com  Tue Aug 23 00:02:44 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Tue, 23 Aug 2011 00:02:44 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
Message-ID: <OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>


Hi all,

I've been following this thread with interest, as it touches on some of the
more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated as
a simple string or as HTML content. And that's the very thing that typed
literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type is
supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types in
both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than XMLLiteral
eliminates the "benefit" of the special rdf:parseType="Literal" syntax. And
without that, I don't see a particular benefit in the stricter XHTML
syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I believe
that, strictly, the XHTML namespace is required for the elements to be
valid XHTML. But I found no hint of this in the spec or any examples, and
certainly RTC doesn't do this (I haven't checked other providers).
Moreover, I believe it's also a worse approach, since there's no guarantee
that your RDF runtime of choice will give you access to namespaces declared
on the property element (I don't believe Jena does), and detecting a
namespace inside the element content would require actually parsing the
value as XML. If all you want to do is pass markup along for display in a
browser, it would be unfortunate to have to actually parse the content to
determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably just
as good as, if not better than, XHTML. Rather than worrying about whether
the content is well-formed XML, it's probably sufficient to just give it to
the browser and see what it can do with it. I would assert that "something
a browser can render" has been the working definition of HTML for a good
number of years now, while XHTML has largely faded in importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it via
OSLC. Likewise, a consumer may use a rich text control that yields HTML.
Generalized parsing of HTML for conversion to XHTML is non-trivial, and it
seems unfortunate to impose that conversion task onto everyone, just so
that we can use rdf:parseType="Literal" in RDF/XML and avoid applying
normal XML encoding to markup content (of course, some encoding will likely
be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if they
all do make perfect sense (and I'm not necessarily claiming they do), I
realize we may be well past the point of being able to act on them. Still,
I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property needed
to change. This is a related, but separate, topic, which I'd be thrilled to
discuss further, but I don't want to open too many cans of worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                             
  From:       Adam Archer/Toronto/IBM at IBMCA                                                                  
                                                                                                             
  To:         Arthur Ryman/Toronto/IBM at IBMCA                                                                 
                                                                                                             
  Cc:         "oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson                      
              <hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net                                      
                                                                                                             
  Date:       08/22/2011 06:20 PM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             
  Sent by:    oslc-core-bounces at open-services.net                                                            
                                                                                                             





The big concern to me is not the ability to process the RDF/XML with XPath,
it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply taking
the content of the attribute, decoding it (which browsers are very good at)
and slapping the result into the dom (which browsers are also very good
at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I don't
even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine what
the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From:        Arthur Ryman/Toronto/IBM
To:        Samuel Padgett <spadgett at us.ibm.com>
Cc:        Adam Archer/Toronto/IBM at IBMCA, Randy Hudson
<hudsonr at us.ibm.com>, "oslc-core at open-services.net"
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net
Date:        08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one point
we tried to define an OSLC-variant of RDF/XML that looked like "normal"
XML. However, we abandonned that and now require support for generic
RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an RDF
toolkit like Jena.

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                   Twitter | Facebook | YouTube   
                                                                                
                                                                                
                                                                                





                                                                           
 From:    Samuel Padgett <spadgett at us.ibm.com>                             
                                                                           
 To:      "oslc-core at open-services.net" <oslc-core at open-services.net>      
                                                                           
 Cc:      Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
                                                                           
                                                                           
 Date:    08/07/2011 01:01 PM                                              
                                                                           
 Subject: [oslc-core] OSLC Compact representation, titles with markup      
                                                                           
                                                                           
 Sent by: oslc-core-bounces at open-services.net                              
                                                                           
                                                                           







I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

 <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

 <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

 <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110823/42ed4e89/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19967617.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19394555.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0003.gif>

From sspeiche at us.ibm.com  Tue Aug 23 09:13:55 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 23 Aug 2011 09:13:55 -0400
Subject: [oslc-core] REMINDER: Core WG Meeting tomorrow (Wed Aug 24) 10:00 ET
Message-ID: <OFE7F482C2.46469320-ON852578F5.00472DA8-852578F5.0048AF8A@us.ibm.com>

Date: Wednesday, 24 August 2011
Time: 10:00 AM Eastern

Agenda:
 - General news
 - Time / date of meeting (some have hard conflict)
 - 2.0 spec issues
  - ui preview label encoding
  - json rep ambiguities
 - 3.0 themes, priorities and timeline development

http://open-services.net/bin/view/Main/OslcCoreMeetings

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




From ryman at ca.ibm.com  Tue Aug 23 10:10:06 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 23 Aug 2011 10:10:06 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
Message-ID: <OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DD584@ca.ibm.com>

Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 
datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 
parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 
preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 
However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 
since it impairs interoperability.

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

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/23/2011 12:06 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 
use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 
of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 
a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 
in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 
XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 
note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 
syntax. And without that, I don't see a particular benefit in the stricter 
XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 
consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 
"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 
I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do


From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Tue Aug 23 10:40:18 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 23 Aug 2011 10:40:18 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
Message-ID: <OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.00509995@ca.ibm.com>

Adam,

Your argument for escaping HTML is based purely on the use case of compact 
rendering. However, the OSLC specs are designed to enable many other use 
cases and to promote general interoperability among different tools.

The OSLC core spec provides guidelines for the use of some common RDF 
properties, including those from the Dublin Core. [1] dcterms:title and 
dcterms:description in general contain text that may include formatting 
information. There were several candidates for syntax - HTML, Wiki, RTF. 
The RDF spec contains the means for including XML literals, and XHTML is 
the W3C standard for formatted text. All the other text formats are 
convertible to XHTML. It was therefore chosen as the recommended way to 
package rich text.

The historical design of Jazz compact rendering is optimized for 
consumption by web browsers. However, the RDF plain text datatype does NOT 
imply that the text is HTML encoded. Another processor would be justified 
in displaying the verbatim encoding.

However, for the case of OSLC preview, I see no reason why the text 
couldn't be encoded, but it should be put in a property that makes that 
clear, e.g. oslc:htmlEncodedTitle.

FYI, I work on Focal Point and its REST API provides both a plain text and 
a marked up text version of some attributes.

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

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Adam Archer/Toronto/IBM
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Samuel Padgett <spadgett at us.ibm.com>, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:
08/22/2011 05:00 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at).

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:   Arthur Ryman/Toronto/IBM
To:     Samuel Padgett <spadgett at us.ibm.com>
Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net







From spadgett at us.ibm.com  Tue Aug 23 11:11:38 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Tue, 23 Aug 2011 11:11:38 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
Message-ID: <OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@us.ibm.com>

Hi, Arthur. Thanks for the answers. It clears some things up for me.

Arthur Ryman <ryman at ca.ibm.com> wrote on 08/22/2011 04:40:25 PM:

> I don't think problems using XPath are a valid reason to encode markup
> since RDF/XML itselt is very difficult to process using XPath. At one
> point we tried to define an OSLC-variant of RDF/XML that looked like
> "normal" XML. However, we abandonned that and now require support for
> generic RDF/XML.

To make sure I understand: By generic RDF/XML, you are talking about what
the spec calls "constrained RDF/XML" in Appendix B, right? [1]

> The are many equivalent ways to represent a given set of triples in
> RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
> XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
> RDF toolkit like Jena.

This makes sense, and I agree. But for me it also raises a few questions:

- Do we need a JSON Compact representation for consumers who don't use an
RDF library? This is one of the few resources in OSLC that doesn't have a
JSON representation, and it seems natural since so often the consumer here
is a web client.

- Should we define a "constrained RDF/XML" representation if our
recommendation is to use an RDF toolkit anyway? JSON might be a reasonable
alternative for those who don't want RDF/XML.

Best Regards,
Sam

[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_application_xml




From hudsonr at us.ibm.com  Tue Aug 23 10:36:19 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Tue, 23 Aug 2011 10:36:19 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
	<OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
	<OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>
Message-ID: <OF9BE55011.703713F3-ON852578F5.004E4930-852578F5.00503AAD@us.ibm.com>

I don't think the value's datatype is the same as the parseType.  The data
is [X]HTML, no matter what.  It is typically encoded, because that's the
way you store a value in XML, and as long as you follow standard XML
practice, using XPath to extract it has been pretty straightforward.  For
better or worse, RDF/XML supports the use of parseType, but many OSLC
consumers out there today are not going to handle documents that chose to
use parseType.

Also, the value really needs to be a snippet of HTML, not XHTML.  Existing
consumers are taking the value as if it were HTML and putting (after
sanitizing) it directly in an existing HTML page.  I'm sure there would be
problems consuming an XHTML snippet, for example, one that chose to assign
the XHTML to a non-default namespace.

FWIW, there are other places where OSLC deviates from what RDF/XML allows.
e.g., requiring the use of absolute URIs.

-Randy



|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" <oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel       |
  |Padgett/Durham/IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS                                                                                      |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/22/2011 04:55 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Randy,

I think example [3] is wrong. If the datatype is plain text then you
should not assume it contains encoded HTML. If you need to include markup
then you should use XML Literal datatype, and use XHTML content. This is
described in the core spec [4] which gives guidance for putting markup in
dcterms:title and dcterms:description.

[4]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties


Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube







From:
Randy Hudson <hudsonr at us.ibm.com>
To:
Samuel Padgett <spadgett at us.ibm.com>, Steve K Speicher
<sspeiche at us.ibm.com>
Cc:
Adam Archer/Toronto/IBM at IBMCA, "oslc-core at open-services.net"
<oslc-core at open-services.net>
Date:
08/08/2011 11:54 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be
wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |Samuel Padgett/Durham/IBM                              |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| To:        |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |oslc-core at open-services.net <oslc-core at open-services.net>            |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Cc:        |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA
                   |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Date:      |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |08/07/2011 01:06 PM                        |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Subject:   |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |OSLC Compact representation, titles with markup         |

>--------------------------------------------------------------------------------------------------------------------------------------------------|





Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net








From agarcher at ca.ibm.com  Tue Aug 23 11:35:57 2011
From: agarcher at ca.ibm.com (Adam Archer)
Date: Tue, 23 Aug 2011 11:35:57 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.004F6D01@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
	<OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.004F6D01@LocalDomain>
Message-ID: <OFD60830E3.3177897D-ON852578F5.00553E12-852578F5.0055B063@ca.ibm.com>

Arthur,

I understand that OSLC is taking a larger problem domain into account when 
defining syntax and data types, but I'm not arguing about that. I'm 
arguing that in the specific case of the compact spec, it makes it much 
less consumable. Generalizing is not always a good thing if it makes life 
more difficult for some of the cases. Perhaps what you are suggesting with 
the oslc:htmlEncodedTitle idea is the right way to address this, but all 
I'm advocating is that we not make this more complicated for consumers 
than it has been for the last 3 years. If that means a change to the spec, 
so be it.

Adam Archer
Jazz Developer
IBM Toronto Lab



From:   Arthur Ryman/Toronto/IBM
To:     Adam Archer/Toronto/IBM at IBMCA
Cc:     Randy Hudson <hudsonr at us.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel 
Padgett <spadgett at us.ibm.com>
Date:   08/23/2011 10:40 AM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Adam,

Your argument for escaping HTML is based purely on the use case of compact 
rendering. However, the OSLC specs are designed to enable many other use 
cases and to promote general interoperability among different tools.

The OSLC core spec provides guidelines for the use of some common RDF 
properties, including those from the Dublin Core. [1] dcterms:title and 
dcterms:description in general contain text that may include formatting 
information. There were several candidates for syntax - HTML, Wiki, RTF. 
The RDF spec contains the means for including XML literals, and XHTML is 
the W3C standard for formatted text. All the other text formats are 
convertible to XHTML. It was therefore chosen as the recommended way to 
package rich text.

The historical design of Jazz compact rendering is optimized for 
consumption by web browsers. However, the RDF plain text datatype does NOT 
imply that the text is HTML encoded. Another processor would be justified 
in displaying the verbatim encoding.

However, for the case of OSLC preview, I see no reason why the text 
couldn't be encoded, but it should be put in a property that makes that 
clear, e.g. oslc:htmlEncodedTitle.

FYI, I work on Focal Point and its REST API provides both a plain text and 
a marked up text version of some attributes.

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

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Adam Archer/Toronto/IBM
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Samuel Padgett <spadgett at us.ibm.com>, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:
08/22/2011 05:00 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at).

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:   Arthur Ryman/Toronto/IBM
To:     Samuel Padgett <spadgett at us.ibm.com>
Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110823/9ba80559/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0003.gif>

From sspeiche at us.ibm.com  Tue Aug 23 12:09:21 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 23 Aug 2011 12:09:21 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@us.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
	<OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@us.ibm.com>
Message-ID: <OF44A54CE2.FBFEAA8D-ON852578F5.00584E63-852578F5.0058BF38@us.ibm.com>

One thing I was going to point out, that the only representation supported 
is XML for Compact (not RDF/XML or JSON).

"The Compact representation MUST be in the XML format described in this 
document" 

I've queued this discussion as an issue to be discussed in Core WG

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


oslc-core-bounces at open-services.net wrote on 08/23/2011 11:11:38 AM:

> From: Samuel Padgett/Durham/IBM at IBMUS
> To: Arthur Ryman <ryman at ca.ibm.com>, 
> Cc: Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-
> core at open-services.net>, Randy Hudson/Raleigh/IBM at IBMUS, oslc-core-
> bounces at open-services.net
> Date: 08/23/2011 11:24 AM
> Subject: Re: [oslc-core] OSLC Compact representation, titles with markup
> Sent by: oslc-core-bounces at open-services.net
> 
> Hi, Arthur. Thanks for the answers. It clears some things up for me.
> 
> Arthur Ryman <ryman at ca.ibm.com> wrote on 08/22/2011 04:40:25 PM:
> 
> > I don't think problems using XPath are a valid reason to encode markup
> > since RDF/XML itselt is very difficult to process using XPath. At one
> > point we tried to define an OSLC-variant of RDF/XML that looked like
> > "normal" XML. However, we abandonned that and now require support for
> > generic RDF/XML.
> 
> To make sure I understand: By generic RDF/XML, you are talking about 
what
> the spec calls "constrained RDF/XML" in Appendix B, right? [1]
> 
> > The are many equivalent ways to represent a given set of triples in
> > RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
> > XQuery to process RDF/XML. The safe way to process RDF/XML is to use 
an
> > RDF toolkit like Jena.
> 
> This makes sense, and I agree. But for me it also raises a few 
questions:
> 
> - Do we need a JSON Compact representation for consumers who don't use 
an
> RDF library? This is one of the few resources in OSLC that doesn't have 
a
> JSON representation, and it seems natural since so often the consumer 
here
> is a web client.
> 
> - Should we define a "constrained RDF/XML" representation if our
> recommendation is to use an RDF toolkit anyway? JSON might be a 
reasonable
> alternative for those who don't want RDF/XML.
> 
> Best Regards,
> Sam
> 
> [1]
> 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?

> sortcol=table;up=#Guidelines_for_application_xml
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net




From spadgett at us.ibm.com  Tue Aug 23 15:14:01 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Tue, 23 Aug 2011 15:14:01 -0400
Subject: [oslc-core] Minor problem in JSON Service Provider Resource example
Message-ID: <OF668F4399.44D2378F-ON852578F5.0068F15E-852578F5.0069B312@us.ibm.com>


Minor problem in the JSON Service Provider Resource example [1]: It looks
like 'service' should be 'oslc:service', and the value should be a JSON
array rather than a JSON object since it occurs 'one-or-many' [2].

- Best Regards, Sam

[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecJSONExamples?sortcol=table;up=#Service_Provider_Resource
[2]
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Service_Provider_Resources




From ryman at ca.ibm.com  Tue Aug 23 15:14:51 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 23 Aug 2011 15:14:51 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFD60830E3.3177897D-ON852578F5.00553E12-852578F5.00559CCB@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
	<OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.004F6D01@LocalDomain>
	<OFD60830E3.3177897D-ON852578F5.00553E12-852578F5.00559CCB@LocalDomain>
Message-ID: <OF9A5008D5.3F2D2835-ON852578F5.006973E3-852578F5.0069BAD4@ca.ibm.com>


Adam,

Yes, I am suggesting that when people use dcterms:title they represent
markup via XML Literal rather than HTML encoding. It think it would be
cleaner to use a special purpose property for literals that were encoded
HTML, e.g. oslc:htmlEncodedTitle.

Regards,
___________________________________________________________________________
                                                                               
 Arthur Ryman                                                                  
                                                                               
 DE, PPM Chief Architect                                                       
                                                                               
 IBM Software, Rational                                                        
                                                                               
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |  
                                                                      YouTube  
                                                                               
                                                                               
                                                                               




|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer/Toronto/IBM                                                                                                                           |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman/Toronto/IBM at IBMCA                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson <hudsonr at us.ibm.com>, "oslc-core at open-services.net" <oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel       |
  |Padgett <spadgett at us.ibm.com>                                                                                                                     |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/23/2011 11:35 AM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Arthur,

I understand that OSLC is taking a larger problem domain into account when
defining syntax and data types, but I'm not arguing about that. I'm arguing
that in the specific case of the compact spec, it makes it much less
consumable. Generalizing is not always a good thing if it makes life more
difficult for some of the cases. Perhaps what you are suggesting with the
oslc:htmlEncodedTitle idea is the right way to address this, but all I'm
advocating is that we not make this more complicated for consumers than it
has been for the last 3 years. If that means a change to the spec, so be
it.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:	Arthur Ryman/Toronto/IBM
To:	Adam Archer/Toronto/IBM at IBMCA
Cc:	Randy Hudson <hudsonr at us.ibm.com>,
            "oslc-core at open-services.net" <oslc-core at open-services.net>,
            oslc-core-bounces at open-services.net, Samuel Padgett
            <spadgett at us.ibm.com>
Date:	08/23/2011 10:40 AM
Subject:	Re: [oslc-core] OSLC Compact representation, titles with markup


Adam,

Your argument for escaping HTML is based purely on the use case of compact
rendering. However, the OSLC specs are designed to enable many other use
cases and to promote general interoperability among different tools.

The OSLC core spec provides guidelines for the use of some common RDF
properties, including those from the Dublin Core. [1] dcterms:title and
dcterms:description in general contain text that may include formatting
information. There were several candidates for syntax - HTML, Wiki, RTF.
The RDF spec contains the means for including XML literals, and XHTML is
the W3C standard for formatted text. All the other text formats are
convertible to XHTML. It was therefore chosen as the recommended way to
package rich text.

The historical design of Jazz compact rendering is optimized for
consumption by web browsers. However, the RDF plain text datatype does NOT
imply that the text is HTML encoded. Another processor would be justified
in displaying the verbatim encoding.

However, for the case of OSLC preview, I see no reason why the text
couldn't be encoded, but it should be put in a property that makes that
clear, e.g. oslc:htmlEncodedTitle.

FYI, I work on Focal Point and its REST API provides both a plain text and
a marked up text version of some attributes.

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

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |   
                                                                      YouTube   
                                                                                
                                                                                
                                                                                





|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer/Toronto/IBM                                                                                                                           |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman/Toronto/IBM at IBMCA                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett <spadgett at us.ibm.com>, Randy Hudson <hudsonr at us.ibm.com>, "oslc-core at open-services.net" <oslc-core at open-services.net>,             |
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/22/2011 05:00 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




The big concern to me is not the ability to process the RDF/XML with XPath,
it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply taking
the content of the attribute, decoding it (which browsers are very good at)
and slapping the result into the dom (which browsers are also very good
at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I don't
even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine what
the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:	Arthur Ryman/Toronto/IBM
To:	Samuel Padgett <spadgett at us.ibm.com>
Cc:	Adam Archer/Toronto/IBM at IBMCA, Randy Hudson
            <hudsonr at us.ibm.com>, "oslc-core at open-services.net"
            <oslc-core at open-services.net>,
            oslc-core-bounces at open-services.net
Date:	08/22/2011 04:40 PM
Subject:	Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one point
we tried to define an OSLC-variant of RDF/XML that looked like "normal"
XML. However, we abandonned that and now require support for generic
RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an RDF
toolkit like Jena.

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |   
                                                                      YouTube   
                                                                                
                                                                                
                                                                                





|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett <spadgett at us.ibm.com>                                                                                                              |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"oslc-core at open-services.net" <oslc-core at open-services.net>                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:01 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |[oslc-core] OSLC Compact representation, titles with markup                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|






I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110823/ebec2025/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12845780.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12047798.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0003.gif>

From davidms at ca.ibm.com  Wed Aug 24 15:01:19 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Wed, 24 Aug 2011 15:01:19 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
Message-ID: <OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>


Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a
convenience, but only if tools supported that. As far as I could find, Jena
provides no fine-grained access to namespace declarations (i.e. other than
at the model level), so I believe that one couldn't use it to produce or
consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. That
was very helpful for me. But I must admit, I'm still left wondering what
makes XHTML superior to HTML for interchanging formatted text, especially
in light of the compact representation example and my own experiences,
where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so
odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of this
is acknowledged or explained anywhere. It looks like using a typed literal
in this one case is accepted merely as a requirement to benefit from the
prettier RDF/XML syntax for XML content. However, I view things completely
in the opposite light. To me, typed literals are a powerful benefit of RDF.
You can use a typed literal to decide how to handle a literal value,
without looking at the value itself, but that advantage is lost without a
sufficiently specific type. Thus, I don't understand how defining and using
a new RDF datatype to identify something as widely recognized and
understood as HTML would impair interoperability. I think it would do the
opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                             
  From:       Arthur Ryman/Toronto/IBM                                                                       
                                                                                                             
  To:         Dave Steinberg/Toronto/IBM at IBMCA                                                               
                                                                                                             
  Cc:         oslc-core at open-services.net, oslc-core-bounces at open-services.net                               
                                                                                                             
  Date:       08/23/2011 10:09 AM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             




Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF
datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The
parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. There
are converter from HTML to XHTML, e.g. Tidy. However, in the case of
preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.
However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF etc.
would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged
since it impairs interoperability.

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

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |   
                                                                      YouTube   
                                                                                
                                                                                
                                                                                





                                                                                                             
  From:       Dave Steinberg/Toronto/IBM at IBMCA                                                               
                                                                                                             
  To:         oslc-core at open-services.net                                                                    
                                                                                                             
  Date:       08/23/2011 12:06 AM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             
  Sent by:    oslc-core-bounces at open-services.net                                                            
                                                                                                             





Hi all,

I've been following this thread with interest, as it touches on some of the
more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated as
a simple string or as HTML content. And that's the very thing that typed
literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type is
supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types in
both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than XMLLiteral
eliminates the "benefit" of the special rdf:parseType="Literal" syntax. And
without that, I don't see a particular benefit in the stricter XHTML
syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I believe
that, strictly, the XHTML namespace is required for the elements to be
valid XHTML. But I found no hint of this in the spec or any examples, and
certainly RTC doesn't do this (I haven't checked other providers).
Moreover, I believe it's also a worse approach, since there's no guarantee
that your RDF runtime of choice will give you access to namespaces declared
on the property element (I don't believe Jena does), and detecting a
namespace inside the element content would require actually parsing the
value as XML. If all you want to do is pass markup along for display in a
browser, it would be unfortunate to have to actually parse the content to
determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably just
as good as, if not better than, XHTML. Rather than worrying about whether
the content is well-formed XML, it's probably sufficient to just give it to
the browser and see what it can do with it. I would assert that "something
a browser can render" has been the working definition of HTML for a good
number of years now, while XHTML has largely faded in importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it via
OSLC. Likewise, a consumer may use a rich text control that yields HTML.
Generalized parsing of HTML for conversion to XHTML is non-trivial, and it
seems unfortunate to impose that conversion task onto everyone, just so
that we can use rdf:parseType="Literal" in RDF/XML and avoid applying
normal XML encoding to markup content (of course, some encoding will likely
be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if they
all do make perfect sense (and I'm not necessarily claiming they do), I
realize we may be well past the point of being able to act on them. Still,
I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property needed
to change. This is a related, but separate, topic, which I'd be thrilled to
discuss further, but I don't want to open too many cans of worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Inactive hide details for Adam Archer---08/22/2011 06:20:05 PM---The big
concern to me is not the ability to process the RDF/XMAdam
Archer---08/22/2011 06:20:05 PM---The big concern to me is not the ability
to process the RDF/XML with XPath, it's the ability to do
                                                                           
                                                                           
 From:    Adam Archer/Toronto/IBM at IBMCA                                    
                                                                           
                                                                           
 To:      Arthur Ryman/Toronto/IBM at IBMCA                                   
                                                                           
                                                                           
 Cc:      "oslc-core at open-services.net" <oslc-core at open-services.net>,     
          Randy Hudson <hudsonr at us.ibm.com>,                               
          oslc-core-bounces at open-services.net                              
                                                                           
                                                                           
 Date:    08/22/2011 06:20 PM                                              
                                                                           
                                                                           
 Subject: Re: [oslc-core] OSLC Compact representation, titles with markup  
                                                                           
                                                                           
 Sent by: oslc-core-bounces at open-services.net                              
                                                                           





The big concern to me is not the ability to process the RDF/XML with XPath,
it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply taking
the content of the attribute, decoding it (which browsers are very good at)
and slapping the result into the dom (which browsers are also very good
at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I don't
even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine what
the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one point
we tried to define an OSLC-variant of RDF/XML that looked like "normal"
XML. However, we abandonned that and now require support for generic
RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an RDF
toolkit like Jena.

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                   Twitter | Facebook | YouTube   
                                                                                
                                                                                
                                                                                




                                                                           
 From:   Samuel Padgett <spadgett at us.ibm.com>                              
                                                                           
 To:     "oslc-core at open-services.net" <oslc-core at open-services.net>       
                                                                           
 Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>  
                                                                           
 Date:   08/07/2011 01:01 PM                                               
                                                                           
 Subject [oslc-core] OSLC Compact representation, titles with markup       
 :                                                                         
                                                                           
 Sent    oslc-core-bounces at open-services.net                               
 by:                                                                       
                                                                           







I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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

_______________________________________________
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/20110824/f29be9da/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16248338.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16539910.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0003.gif>

From sspeiche at us.ibm.com  Wed Aug 24 15:13:24 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Wed, 24 Aug 2011 15:13:24 -0400
Subject: [oslc-core] OSLC Core WG Minutes: August 24, 2011
Message-ID: <OF0BB3350E.4EE7A509-ON852578F6.0069422A-852578F6.00699900@us.ibm.com>

http://open-services.net/bin/view/Main/OslcCoreMeeting20110824

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




From sspeiche at us.ibm.com  Wed Aug 24 15:41:11 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Wed, 24 Aug 2011 15:41:11 -0400
Subject: [oslc-core] OSLC Core WG Meeting Day/Time Survey -- Please Respond
Message-ID: <OFFFB1A464.E6A3D81D-ON852578F6.006B6AC9-852578F6.006C2440@us.ibm.com>

Survey link: http://doodle.com/n5bef5gepvx2fhaw

Using dates 2 weeks from now just as an example.  Pick a day/time of week 
that works, even if it doesn't work for this one week.

Let me know if there are any questions.

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




From ryman at ca.ibm.com  Thu Aug 25 16:32:02 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Thu, 25 Aug 2011 16:32:02 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
Message-ID: <OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>

Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 
http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 
literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 
There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 
suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 
it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 
convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 
than at the model level), so I believe that one couldn't use it to produce 
or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 
odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 
datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 
parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 
preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 
However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 
since it impairs interoperability.

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


Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 
thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 
use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 
of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 
a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 
in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 
XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 
note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 
syntax. And without that, I don't see a particular benefit in the stricter 
XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 
consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 
"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 
I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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

_______________________________________________
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






From ryman at ca.ibm.com  Thu Aug 25 16:47:05 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Thu, 25 Aug 2011 16:47:05 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
	<OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@LocalDomain>
Message-ID: <OF8B61EA2A.1229F837-ON852578F7.00708173-852578F7.00722E69@ca.ibm.com>

Sam,

By "generic RDF/XML" I mean arbitrary, unconstrained RDF/XML. We started 
out trying to define a constrained RDF/XML for general use because we 
thought it would be easier to parse with standard XML technologies. 
However, we did not want to pay the price of defining this precisely, 
having a validator, etc. We soon found it was very hard to entice toolkits 
to generate RDF/XML that precisely fit our design. The closest we came was 
the so-called Abbreviated RDF/XML in Jena. There was no spec for that. I 
assume it's just supposed to be easier to read by humans. In the end we 
decided to abandon that approach and simply adopt the W3C RDF/XML spec.

However, as a legacy, that compact UI spec still used the constrained 
RDF/XML. However, we don't call it RDF. It's content type is 
application/xml. It just happens to also be valid RDF/XML but service 
providers are not allowed to use unconstrained RDF/XML. They have to 
generate precisely that format. We could even have written an XSD to 
describe the format. The goal was to make it easy to parse in browsers, 
i.e. not require full browser-based RDF parsers.

Yes, it would have made sense to use JSON for this purpose since browsers 
can more easily parse that. However, as a general rule, we want to 
minimize the number of formats a service provider has to support. This XML 
format is a MUST.

___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Samuel Padgett/Durham/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Randy 
Hudson/Raleigh/IBM at IBMUS
Date:
08/23/2011 11:12 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Hi, Arthur. Thanks for the answers. It clears some things up for me.

Arthur Ryman <ryman at ca.ibm.com> wrote on 08/22/2011 04:40:25 PM:

> I don't think problems using XPath are a valid reason to encode markup 
> since RDF/XML itselt is very difficult to process using XPath. At one 
> point we tried to define an OSLC-variant of RDF/XML that looked like 
> "normal" XML. However, we abandonned that and now require support for 
> generic RDF/XML.

To make sure I understand: By generic RDF/XML, you are talking about what 
the spec calls "constrained RDF/XML" in Appendix B, right? [1]

> The are many equivalent ways to represent a given set of triples in 
> RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
> XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
> RDF toolkit like Jena.

This makes sense, and I agree. But for me it also raises a few questions:

- Do we need a JSON Compact representation for consumers who don't use an 
RDF library? This is one of the few resources in OSLC that doesn't have a 
JSON representation, and it seems natural since so often the consumer here 
is a web client.

- Should we define a "constrained RDF/XML" representation if our 
recommendation is to use an RDF toolkit anyway? JSON might be a reasonable 
alternative for those who don't want RDF/XML.

Best Regards,
Sam

[1] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_application_xml





From ryman at ca.ibm.com  Thu Aug 25 16:47:05 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Thu, 25 Aug 2011 16:47:05 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF9BE55011.703713F3-ON852578F5.004E4930-852578F5.00503AAD@LocalDomain>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
	<OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
	<OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>
	<OF9BE55011.703713F3-ON852578F5.004E4930-852578F5.00503AAD@LocalDomain>
Message-ID: <OF5FCD697E.449D13FA-ON852578F7.00719240-852578F7.00722E6C@ca.ibm.com>

Randy,

OSLC now supports W3C RDF/XML. This means all URIs are absolute although 
you  might compute them relative to the xml:base. But that is standard 
RDF/XML. Do you have an example where OSLC deviates from RDF/XML?

In RDF/XML the attribute rdf:parseType="Literal" means that the datatype 
is XMLLiteral.

I think I addressed your other comments in other responses.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel 
Padgett/Durham/IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS
Date:
08/23/2011 10:36 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


I don't think the value's datatype is the same as the parseType.  The data 
is [X]HTML, no matter what.  It is typically encoded, because that's the 
way you store a value in XML, and as long as you follow standard XML 
practice, using XPath to extract it has been pretty straightforward.  For 
better or worse, RDF/XML supports the use of parseType, but many OSLC 
consumers out there today are not going to handle documents that chose to 
use parseType.

Also, the value really needs to be a snippet of HTML, not XHTML.  Existing 
consumers are taking the value as if it were HTML and putting (after 
sanitizing) it directly in an existing HTML page.  I'm sure there would be 
problems consuming an XHTML snippet, for example, one that chose to assign 
the XHTML to a non-default namespace.

FWIW, there are other places where OSLC deviates from what RDF/XML allows. 
 e.g., requiring the use of absolute URIs.

-Randy





From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel 
Padgett/Durham/IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS
Date:
08/22/2011 04:55 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

I think example [3] is wrong. If the datatype is plain text then you 
should not assume it contains encoded HTML. If you need to include markup 
then you should use XML Literal datatype, and use XHTML content. This is 
described in the core spec [4] which gives guidance for putting markup in 
dcterms:title and dcterms:description.

[4] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties


Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Randy Hudson <hudsonr at us.ibm.com>
To:
Samuel Padgett <spadgett at us.ibm.com>, Steve K Speicher 
<sspeiche at us.ibm.com>
Cc:
Adam Archer/Toronto/IBM at IBMCA, "oslc-core at open-services.net" 
<oslc-core at open-services.net>
Date:
08/08/2011 11:54 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be 
wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett/Durham/IBM                              |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net <oslc-core at open-services.net>            |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA 
                   |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:06 PM                        |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSLC Compact representation, titles with markup         |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net









From hudsonr at us.ibm.com  Thu Aug 25 19:06:45 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Thu, 25 Aug 2011 19:06:45 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
Message-ID: <OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@us.ibm.com>

The following input is also equivalent:

<dcterms:title
rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
12345: &lt;s xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception
during startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value of
type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
      1.2.1 Inside the XML element add the value as a string with any
      required escaping

That would seem to suggest that the above form should be used.

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/25/2011 04:34 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for
http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the
literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.
There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test
suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,
it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a
convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other
than at the model level), so I believe that one couldn't use it to produce
or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so
odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF
datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The
parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of
preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.
However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged
since it impairs interoperability.

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



Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this
thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"
syntax. And without that, I don't see a particular benefit in the stricter
XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that
"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),
I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From joeross at us.ibm.com  Thu Aug 25 19:30:38 2011
From: joeross at us.ibm.com (Joe Ross)
Date: Thu, 25 Aug 2011 18:30:38 -0500
Subject: [oslc-core] domain URL for Service that supports creation/query of
 Service Provider resources
Message-ID: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>

In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 
We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability.

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec.

Thanks much,

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110825/e23c8a5e/attachment-0002.html>

From ryman at ca.ibm.com  Fri Aug 26 07:59:58 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 07:59:58 -0400
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
Message-ID: <OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>

Joe,

Your Service Provider registry service sounds interesting.

I am a little concerned about you using http://open-services.net/ns/core# 
as the domain since we haven't specified what that would mean. Here is the 
definition of  what a Domain is:

OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
Management, Requirements management or Automation. Each OSLC Domain will 
have its own OSLC specification that complies with this Core 
specification. 

I think we should have a spec that outlines the types of resources in the 
domain. You have selected just one type of  core resource.  Perhaps you 
should specify that and coin a URI for it?

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net
Date:
08/25/2011 10:49 PM
Subject:
[oslc-core] domain URL for Service that supports creation/query of Service 
Provider resources
Sent by:
oslc-core-bounces at open-services.net




In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 
We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability. 

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec. 

Thanks much, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From sspeiche at us.ibm.com  Fri Aug 26 09:08:21 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Fri, 26 Aug 2011 09:08:21 -0400
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
Message-ID: <OF45B1D423.FDCDF929-ON852578F8.0047766A-852578F8.00482D21@us.ibm.com>

Agree that this sounds like an interesting registry.  I also agree that 
what the spec says is quite restrictive in the sense of: 1) it doesn't 
allow for providers that don't fit any domain and 2) along these same 
lines, doesn't allow for pre-spec or proprietary explorations to introduce 
"private domains".

To accommodate these two cases, I see 3 different alternatives:
a. Just use the core namespace as Joe suggested
b. Invent a "private domain" namespace and use that
c. Create an OSLC WG, create a spec to support this, then use that 
namespace

Doing (a) requires us to modify the definition or intention in the spec, 
which I think is the most desirable.  Doing (b) has nice qualities but 
again would make use issue some changes to the spec.  Finally (c) is what 
we have today but requires a little overhead.

If there is the possibility of tweaking the spec, not making oslc:domain 
required on oslc:Service.  Though this has some breaking possibilities 
that we should avoid.  I believe the other options mentioned provide for 
the desired use case without impacting many, if any, clients.

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


> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Joe Ross/Austin/IBM at IBMUS, 
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 08/26/2011 08:00 AM
> Subject: Re: [oslc-core] domain URL for Service that supports 
creation/query
> of Service Provider resources
> Sent by: oslc-core-bounces at open-services.net
> 
> Joe,
> 
> Your Service Provider registry service sounds interesting.
> 
> I am a little concerned about you using 
http://open-services.net/ns/core# 
> as the domain since we haven't specified what that would mean. Here is 
the 
> definition of  what a Domain is:
> 
> OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
> Management, Requirements management or Automation. Each OSLC Domain will 

> have its own OSLC specification that complies with this Core 
> specification. 
> 
> I think we should have a spec that outlines the types of resources in 
the 
> domain. You have selected just one type of  core resource.  Perhaps you 
> should specify that and coin a URI for it?
> 
> Regards, 
> 
___________________________________________________________________________ 

> 
> Arthur Ryman 
> 
> DE, PPM & Reporting Chief Architect
> IBM Software, Rational 
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 
> 
> 
> 
> 
> 
> From:
> Joe Ross <joeross at us.ibm.com>
> To:
> oslc-core at open-services.net
> Date:
> 08/25/2011 10:49 PM
> Subject:
> [oslc-core] domain URL for Service that supports creation/query of 
Service 
> Provider resources
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> 
> In Tivoli, we are creating a Provider Registry that is itself 
implemented 
> as a Service Provider (a Service Provider for Service Provider 
resources). 
> We want to do this, so that we can support creation of Service Provider 
> records using a Creation Factory and querying for Service Providers 
using 
> a Query Capability. 
> 
> As part of defining the Service, we need to provide an oslc:domain with 
> namespace URI. Does it make sense for us to use the OSLC Core namespace 
> URI  (http://open-services.net/ns/core# ) for this? That seems logical 
> since all of the resources we are supporting in this Provider Registry 
> Service Provider are defined in the OSLC Core spec. 
> 
> Thanks much, 
> 
> ================================================
> Joe Ross/Austin/IBM, joeross at us.ibm.com
> Tivoli Autonomic Computing & Component Technologies
> 512-286-8311, T/L 
363-8311_______________________________________________
> 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




From sspeiche at us.ibm.com  Fri Aug 26 09:25:39 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Fri, 26 Aug 2011 09:25:39 -0400
Subject: [oslc-core] Minor problem in JSON Service Provider Resource
	example
In-Reply-To: <OF668F4399.44D2378F-ON852578F5.0068F15E-852578F5.0069B312@us.ibm.com>
References: <OF668F4399.44D2378F-ON852578F5.0068F15E-852578F5.0069B312@us.ibm.com>
Message-ID: <OFD093B94B.320C13F5-ON852578F8.00492FF1-852578F8.0049C29B@us.ibm.com>

Thanks Sam, made the fix.  After a quick sanity check, I also noticed that 
oslc:queryCapabilty has the same issue as oslc:service (should be an 
array).  Also the oslc:resourceShape (also renamed from oslc:shap) were 
objects and not arrays.  Think I fixed all the issues with it.  I also ran 
it through jslint.org to make sure it was valid still.

Let me know if I missed anything.

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

> From: Samuel Padgett/Durham/IBM at IBMUS
> To: "oslc-core at open-services.net" <oslc-core at open-services.net>, 
> Cc: Kevin Bauer/Raleigh/IBM at IBMUS
> Date: 08/23/2011 03:15 PM
> Subject: [oslc-core] Minor problem in JSON Service Provider Resource 
example
> Sent by: oslc-core-bounces at open-services.net
> 
> 
> Minor problem in the JSON Service Provider Resource example [1]: It 
looks
> like 'service' should be 'oslc:service', and the value should be a JSON
> array rather than a JSON object since it occurs 'one-or-many' [2].
> 
> - Best Regards, Sam
> 
> [1]
> http://open-services.net/bin/view/Main/OSLCCoreSpecJSONExamples?
> sortcol=table;up=#Service_Provider_Resource
> [2]
> http://open-services.net/bin/view/Main/OslcCoreSpecification?
> sortcol=table;up=#Service_Provider_Resources
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 




From joeross at us.ibm.com  Fri Aug 26 09:50:24 2011
From: joeross at us.ibm.com (Joe Ross)
Date: Fri, 26 Aug 2011 08:50:24 -0500
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
Message-ID: <OFBB321C85.89A8EB60-ON862578F8.004B0E99-862578F8.004C0787@us.ibm.com>

Arthr,

We are actually  representing most (if not all) of the core resource types 
(Service, CreationFactory, QueryCapability, etc.) in the Provider Registry 
records.  Basically products register all of their capabilities and access 
points by OSLC core resource records in the Provider Registry. Most of the 
resources are in-line and part of the complete Service Provider record 
being registered. We will probably also need to register Resource Shapes 
and their properties for a complete understanding of provider 
capabilities.

Since these resource types are already defined in the Core specification, 
I would prefer not to have to redefine them all in a domain spec. 

Thanks,

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311



From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Joe Ross/Austin/IBM at IBMUS
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/26/2011 07:00 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources



Joe,

Your Service Provider registry service sounds interesting.

I am a little concerned about you using http://open-services.net/ns/core# 
as the domain since we haven't specified what that would mean. Here is the 

definition of  what a Domain is:

OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
Management, Requirements management or Automation. Each OSLC Domain will 
have its own OSLC specification that complies with this Core 
specification. 

I think we should have a spec that outlines the types of resources in the 
domain. You have selected just one type of  core resource.  Perhaps you 
should specify that and coin a URI for it?

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net
Date:
08/25/2011 10:49 PM
Subject:
[oslc-core] domain URL for Service that supports creation/query of Service 

Provider resources
Sent by:
oslc-core-bounces at open-services.net




In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 

We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability. 

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec. 

Thanks much, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
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/20110826/9db92abb/attachment-0002.html>

From ryman at ca.ibm.com  Fri Aug 26 10:04:31 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 10:04:31 -0400
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OFBB321C85.89A8EB60-ON862578F8.004B0E99-862578F8.004C0787@LocalDomain>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
	<OFBB321C85.89A8EB60-ON862578F8.004B0E99-862578F8.004C0787@LocalDomain>
Message-ID: <OF8A61BF8D.10B96647-ON852578F8.004C38F7-852578F8.004D52E2@ca.ibm.com>

Joe,

I didn't mean to imply you should redefine them. Just reference the core 
spec. Currently, the core spec isn't technically a domain. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross/Austin/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/26/2011 09:50 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources




Arthr, 

We are actually  representing most (if not all) of the core resource types 
(Service, CreationFactory, QueryCapability, etc.) in the Provider Registry 
records.  Basically products register all of their capabilities and access 
points by OSLC core resource records in the Provider Registry. Most of the 
resources are in-line and part of the complete Service Provider record 
being registered. We will probably also need to register Resource Shapes 
and their properties for a complete understanding of provider 
capabilities. 

Since these resource types are already defined in the Core specification, 
I would prefer not to have to redefine them all in a domain spec. 

Thanks, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311 


From: 
Arthur Ryman <ryman at ca.ibm.com> 
To: 
Joe Ross/Austin/IBM at IBMUS 
Cc: 
oslc-core at open-services.net, oslc-core-bounces at open-services.net 
Date: 
08/26/2011 07:00 AM 
Subject: 
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources




Joe,

Your Service Provider registry service sounds interesting.

I am a little concerned about you using http://open-services.net/ns/core# 
as the domain since we haven't specified what that would mean. Here is the 

definition of  what a Domain is:

OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
Management, Requirements management or Automation. Each OSLC Domain will 
have its own OSLC specification that complies with this Core 
specification. 

I think we should have a spec that outlines the types of resources in the 
domain. You have selected just one type of  core resource.  Perhaps you 
should specify that and coin a URI for it?

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net
Date:
08/25/2011 10:49 PM
Subject:
[oslc-core] domain URL for Service that supports creation/query of Service 

Provider resources
Sent by:
oslc-core-bounces at open-services.net




In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 

We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability. 

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec. 

Thanks much, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net










From joeross at us.ibm.com  Fri Aug 26 10:00:31 2011
From: joeross at us.ibm.com (Joe Ross)
Date: Fri, 26 Aug 2011 09:00:31 -0500
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF45B1D423.FDCDF929-ON852578F8.0047766A-852578F8.00482C13@LocalDomain>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
	<OF45B1D423.FDCDF929-ON852578F8.0047766A-852578F8.00482C13@LocalDomain>
Message-ID: <OFE49732DE.42E52B2F-ON862578F8.004BDA7D-862578F8.004CF4BD@us.ibm.com>

Steve,

We would  really prefer option (a). although I guess we could use option 
(b) informally, until necessary spec work is done. I don't think that we 
want to redefine all of the core resource types in another domain.

Even if oslc:domain is not required, there needs to be some property to 
allow clients to understand what kind of Service this is. We are planning 
to use domain to allow clients to select the Service they want to interact 
with.

Thanks,

Joe

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311



From:
Steve K Speicher/Raleigh/IBM
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Joe Ross/Austin/IBM at IBMUS, oslc-core at open-services.net
Date:
08/26/2011 08:08 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources


Agree that this sounds like an interesting registry.  I also agree that 
what the spec says is quite restrictive in the sense of: 1) it doesn't 
allow for providers that don't fit any domain and 2) along these same 
lines, doesn't allow for pre-spec or proprietary explorations to introduce 
"private domains".

To accommodate these two cases, I see 3 different alternatives:
a. Just use the core namespace as Joe suggested
b. Invent a "private domain" namespace and use that
c. Create an OSLC WG, create a spec to support this, then use that 
namespace

Doing (a) requires us to modify the definition or intention in the spec, 
which I think is the most desirable.  Doing (b) has nice qualities but 
again would make use issue some changes to the spec.  Finally (c) is what 
we have today but requires a little overhead.

If there is the possibility of tweaking the spec, not making oslc:domain 
required on oslc:Service.  Though this has some breaking possibilities 
that we should avoid.  I believe the other options mentioned provide for 
the desired use case without impacting many, if any, clients.

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


> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Joe Ross/Austin/IBM at IBMUS, 
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 08/26/2011 08:00 AM
> Subject: Re: [oslc-core] domain URL for Service that supports 
creation/query
> of Service Provider resources
> Sent by: oslc-core-bounces at open-services.net
> 
> Joe,
> 
> Your Service Provider registry service sounds interesting.
> 
> I am a little concerned about you using 
http://open-services.net/ns/core# 
> as the domain since we haven't specified what that would mean. Here is 
the 
> definition of  what a Domain is:
> 
> OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
> Management, Requirements management or Automation. Each OSLC Domain will 

> have its own OSLC specification that complies with this Core 
> specification. 
> 
> I think we should have a spec that outlines the types of resources in 
the 
> domain. You have selected just one type of  core resource.  Perhaps you 
> should specify that and coin a URI for it?
> 
> Regards, 
> 
___________________________________________________________________________ 

> 
> Arthur Ryman 
> 
> DE, PPM & Reporting Chief Architect
> IBM Software, Rational 
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 
> 
> 
> 
> 
> 
> From:
> Joe Ross <joeross at us.ibm.com>
> To:
> oslc-core at open-services.net
> Date:
> 08/25/2011 10:49 PM
> Subject:
> [oslc-core] domain URL for Service that supports creation/query of 
Service 
> Provider resources
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> 
> In Tivoli, we are creating a Provider Registry that is itself 
implemented 
> as a Service Provider (a Service Provider for Service Provider 
resources). 
> We want to do this, so that we can support creation of Service Provider 
> records using a Creation Factory and querying for Service Providers 
using 
> a Query Capability. 
> 
> As part of defining the Service, we need to provide an oslc:domain with 
> namespace URI. Does it make sense for us to use the OSLC Core namespace 
> URI  (http://open-services.net/ns/core# ) for this? That seems logical 
> since all of the resources we are supporting in this Provider Registry 
> Service Provider are defined in the OSLC Core spec. 
> 
> Thanks much, 
> 
> ================================================
> Joe Ross/Austin/IBM, joeross at us.ibm.com
> Tivoli Autonomic Computing & Component Technologies
> 512-286-8311, T/L 
363-8311_______________________________________________
> 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/20110826/7fabc50c/attachment-0002.html>

From ryman at ca.ibm.com  Fri Aug 26 14:22:28 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 14:22:28 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
Message-ID: <OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@ca.ibm.com>

Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 

it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 

convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 

than at the model level), so I believe that one couldn't use it to produce 

or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 

odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 

datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 

parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 

preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 

However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 

since it impairs interoperability.

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



Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 

use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 

of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 

a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 

in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 

XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 

note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 

syntax. And without that, I don't see a particular benefit in the stricter 

XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 

consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 

"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 

I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 

view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 

it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 

(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 

consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From hudsonr at us.ibm.com  Fri Aug 26 14:48:56 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Fri, 26 Aug 2011 14:48:56 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
Message-ID: <OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@us.ibm.com>

Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get
jena to write out the property this way by setting an option on the writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the value's
type in its serialized form in cases where only one datatype is allowed.
It looks like bits of the "schema" get repeated over and over.

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman/Toronto/IBM at IBMCA                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, oslc-core-bounces at open-services.net                                             |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/26/2011 02:22 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________
                                                                              
 Arthur Ryman                                        (Embedded image moved to 
                                                          file: pic19425.gif) 
                                                                              
 DE, PPM & Reporting Chief Architect                                          
                                                                              
 IBM Software, Rational                                                       
                                                                              
 Toronto Lab | +1-905-413-3077 (office) |                                     
 +1-416-939-5063 (mobile)                                                     
                                                                              





|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, oslc-core-bounces at open-services.net                                             |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/25/2011 07:06 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value of
type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
      1.2.1 Inside the XML element add the value as a string with any
      required escaping

That would seem to suggest that the above form should be used.

-Randy



|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/25/2011 04:34 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for
http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the
literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.
There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test
suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,
it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a
convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other
than at the model level), so I believe that one couldn't use it to produce
or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so
odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF
datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The
parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of
preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.
However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged
since it impairs interoperability.

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



Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this
thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"
syntax. And without that, I don't see a particular benefit in the stricter
XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that
"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),
I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic19425.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/b0ca3e53/attachment.gif>

From davidms at ca.ibm.com  Fri Aug 26 15:21:02 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 15:21:02 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
Message-ID: <OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>


Arthur,

I believe you're mistaken. I think that parseType="Literal" is just
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make
it easy to write literals of this kind"). Either way you write it, you end
up with the same statement. Two statements with the same subject, the same
predicate and a typed literal with the same type
(<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with
some sort of privileged XMLLiteral representation that couldn't written out
using any other RDF notation.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com



                                                                                                             
  From:       Arthur Ryman/Toronto/IBM                                                                       
                                                                                                             
  To:         Randy Hudson/Raleigh/IBM at IBMUS                                                                 
                                                                                                             
  Cc:         Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,                              
              oslc-core-bounces at open-services.net                                                            
                                                                                                             
  Date:       08/26/2011 02:22 PM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             





Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,

it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a

convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other

than at the model level), so I believe that one couldn't use it to produce

or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so

odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF

datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The

parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of

preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.

However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged

since it impairs interoperability.

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




Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the

use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use

of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use

a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral

in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other

XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And

note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"

syntax. And without that, I don't see a particular benefit in the stricter

XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a

consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that

"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),

I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of

view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation

it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons

(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all

consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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/20110826/edb5c99c/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/edb5c99c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/edb5c99c/attachment-0001.gif>

From ryman at ca.ibm.com  Fri Aug 26 15:58:50 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 15:58:50 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
Message-ID: <OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006DC2EF@ca.ibm.com>

Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you 
include element content. If you use rdf:datatype then only character 
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal" 
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince 
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 03:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just 
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make 
it easy to write literals of this kind"). Either way you write it, you end 
up with the same statement. Two statements with the same subject, the same 
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same 
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with 
some sort of privileged XMLLiteral representation that couldn't written 
out using any other RDF notation.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the 
content a string that looks like XHTML, i.e. the


From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 


http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 


literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 


There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 


suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 


it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 



Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 


convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 


than at the model level), so I believe that one couldn't use it to produce 


or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 


odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 


- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 


datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 


parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 


the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 


preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 


However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 


since it impairs interoperability.

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




Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 


thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 


use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 


of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 


a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 


in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 


XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 


note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 


syntax. And without that, I don't see a particular benefit in the stricter 


XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 


consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 


"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 


I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 


view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 


it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 


(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 


consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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






From ryman at ca.ibm.com  Fri Aug 26 16:13:52 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:13:52 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
	<OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
Message-ID: <OF8CEBFEC5.987439B3-ON852578F8.006E00F0-852578F8.006F2349@ca.ibm.com>

Randy,

I validated the RDF at the W3C Validator. I've also tried it out via 
Fuseki which uses Jena.

As I said, you can have a datatype of XMLLiteral that happens to include 
just a string which may include escaped characters, e.g. " 1 &lt; 2".  For 
it to be XHTML, it should have elements in the XHTML namespace.

 I just checked the Jena wiki [1]. Note the example:

More about Literals and Datatypes
RDF literals are not just simple strings. Literals may have a language tag 
to indicate the language of the literal. The literal "chat" with an 
English language tag is considered different to the literal "chat" with a 
French language tag. This rather strange behaviour is an artefact of the 
original RDF/XML syntax.
Further there are really two sorts of Literals. In one, the string 
component is just that, an ordinary string. In the other the string 
component is expected to be a well balanced fragment of XML. When an RDF 
Model is written as RDF/XML a special construction using a 
parseType='Literal' attribute is used to represent it.
In Jena, these attributes of a literal may be set when the literal is 
constructed, e.g. in tutorial 11:
// create the resource
Resource r = model.createResource();

// add the property
r.addProperty(RDFS.label, model.createLiteral("chat", "en"))
 .addProperty(RDFS.label, model.createLiteral("chat", "fr"))
 .addProperty(RDFS.label, model.createLiteral("<em>chat</em>", true));

// write out the Model
model.write(system.out);
produces
<rdf:RDF
  xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
  xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#'
 >
  <rdf:Description rdf:nodeID="A0">
    <rdfs:label xml:lang='en'>chat</rdfs:label>
    <rdfs:label xml:lang='fr'>chat</rdfs:label>
    <rdfs:label rdf:parseType='Literal'><em>chat</em></rdfs:label>
  </rdf:Description>
</rdf:RDF>


[1] 
http://jena.sourceforge.net/tutorial/RDF_API/#ch-More%20about%20Literals%20and%20Datatypes

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get 
jena to write out the property this way by setting an option on the 
writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when 
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the 
value's type in its serialized form in cases where only one datatype is 
allowed.  It looks like bits of the "schema" get repeated over and over.

-Randy




From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 






From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 

it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 

convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 

than at the model level), so I believe that one couldn't use it to produce 

or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 

odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 

datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 

parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 

preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 

However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 

since it impairs interoperability.

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



Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 

use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 

of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 

a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 

in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 

XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 

note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 

syntax. And without that, I don't see a particular benefit in the stricter 

XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 

consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 

"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 

I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 

view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 

it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 

(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 

consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net







From ryman at ca.ibm.com  Fri Aug 26 16:28:54 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:28:54 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
	<OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
Message-ID: <OF6FE7077F.DBDB00DB-ON852578F8.006F1789-852578F8.007083BA@ca.ibm.com>

Randy,

For your second question/comment: 

[Off topic]  I'm not sure I really see the benefit to including the 
value's type in its serialized form in cases where only one datatype is 
allowed.  It looks like bits of the "schema" get repeated over and over.

The reason is that there is no "schema" in the usual OO or database sense. 
An RDF property can have any value and be repeated multiple times with 
different values. In the case of OSLC, we try to say what to expect via 
ResourceShapes, and we could "cast" plain literals to the correct data 
value. However, we expect our RDF to be consumed by other applications and 
so we need to include the datatypes to avoid ambiguity, e.g. is "true" a 
boolean or a string?

I do agree that RDF looks very verbose with all the datatypes.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get 
jena to write out the property this way by setting an option on the 
writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when 
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the 
value's type in its serialized form in cases where only one datatype is 
allowed.  It looks like bits of the "schema" get repeated over and over.

-Randy




From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 






From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 

it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 

convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 

than at the model level), so I believe that one couldn't use it to produce 

or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 

odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 

datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 

parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 

preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 

However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 

since it impairs interoperability.

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



Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 

use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 

of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 

a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 

in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 

XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 

note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 

syntax. And without that, I don't see a particular benefit in the stricter 

XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 

consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 

"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 

I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 

view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 

it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 

(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 

consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net







From davidms at ca.ibm.com  Fri Aug 26 16:37:55 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 16:37:55 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
Message-ID: <OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@ca.ibm.com>


Hi again Arthur,

Lots of good points to address, so my responses are inline (also note that
I wrote my previous, short reply to your later message in the middle of
writing this longer one, so there may be a bit of overlap).

[Disclaimer: I realize I'm talking a lot about Jena in this message. That's
because it's what I know. If there are other RDF toolkits in use, their
behaviour is certainly relevant, too, and it would be good to hear from
people with knowledge of them.]

Arthur Ryman/Toronto/IBM wrote on 08/25/2011 04:27:40 PM:
>
> 1. XML Namespaces.
>
> The spec doesn't say "for XHTML, you need to insert an xmlns attribute
for
> http://www.w3.org/1999/xhtml" because that is part of the XHTML
> standard, i.e. it's not XHTML unless the elements are in the XHTML
namespace.

I agree that XHTML does mean using the XHTML namespace, but I also believe
it would have been helpful to underline that fact in the OSLC Core spec.
Also, I still can't find a single example in the spec that actually shows
markup in the value of an XMLLiteral-typed literal, which also would have
been helpful. I notice that RTC doesn't use a namespace, so I suppose it
wasn't obvious to them.

> 2. Jena
>
> I loaded the sample RDF/XML  into Fuseki which uses Jena and it
> produced the correct result. I assume the Jena API lets you get an
> XML DOM from the literal value.

Thanks for this! I didn't know this, and it's reassuring. I was able to
replicate this behaviour with pure Jena, simply by loading an RDF/XML
resource containing your input and printing the type and lexical form of
the literal:

Datatype: http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
Lexical form:  12345: <s xmlns="http://www.w3.org/1999/xhtml">Null pointer
exception during startup</s>

Unfortunately, though, your assumption is not correct: Jena provides no
access to underlying DOM. It appears that during parsing it computes the
exclusive canonical form of the XML subset, as the RDF specs prescribe, and
simply records that as the literal's lexical value. But, Jena's built-in
XMLLiteral type support just uses java.lang.String as its value type. I was
surprised when I first discovered that, too, but you can see for yourself
in XMLLiteralType.parse().

> 3.  XHTML versus HTML
>
> The primary reason is that RDF supports XHTML via the XMLLiteral
> datatype. There is no parsing support for HTML built into RDF.

RDF doesn't require parsing support to use other datatypes, at least not in
the abstract sense. Abstractly, a typed literal is just a datatype
(identified by a URI) and a lexical form. Of course, it's very helpful in
an implementation if you can automatically convert that to a more useful
typed value (i.e. an Integer, Boolean, etc.), but that's purely a toolkit
concern. Jena will support any datatype via its BaseDatatype.TypedValue
wrapper type, but it's pluggable, so you can add specific parsing support
for any type you wish.

> Another strong reason is that the syntax of HTML is very irregular
> and hard to parse correctly - that is one of the reasons XML was
> invented. This is very important from a security viewpoint. To guard
> against script injection attacks, you really should parse the input
> and remove any <script> elements or Javascript attributes. Doing
> that correctly for HTML requires a full HTML parser. On the other
> hand, the XHTML is given to you as a DOM which you can easily
> traverse or process using XSLT or XPATH.

But as you said, HTML Tidy can be used to parse HTML. You could even plug
it in to Jena to do the parsing automatically for a defined datatype, which
would be more convenient than the built in XMLLiteral support. Also, I
really think that whether or not you need to parse and cleanse depends upon
what you're doing with the data. It may not be necessary for an OSLC
adapter that's merely passing along data from a trusted source, since it's
incumbent upon a security-conscious client to do that, itself.

> 4. Datatypes
>
> The specs do specify the datatypes for some properties. Look at the
> Value-Type column of the tables, e.g. [1]. You need to include the
> datatype explicitly for ints, dates, XML. etc. You specify that
> using rdf:datatype in RDF/XML, or using ^^ in Turtle.

Sorry if I wasn't clear. What I meant was that specs don't appear to say
whether consumers and producers should use/expect typed literals or plain
literals. I do see that the tables prescribe datatypes for the various
literal-typed properties, but it doesn't say anywhere whether that means
that typed literals should actually be used to specify those types, or that
plain literals should be used (since those prescribed types are already
presumed to be known).

> 5. Inventing new Datatypes
>
> The RDF spec defines the XSD datatypes and the XMLLiteral datatype.
> RDF parsers know how to parse those. If someone introduces a new
> datatype URI, it could break parsers since they won't know how to
> parse the contents. There is no standard way to define new datatypes.
>
> Try it with the RDF Validation service [2]

I had no problem parsing the following RDF/XML document (in which I've used
my own HTML type) with the service:

<rdf:RDF
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:oslc_cm="http://open-services.net/ns/cm#" >
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title
rdf:datatype="http://open-services.net/ns/core/types#HTML">12345:
&lt;s&gt;Null pointer exception during startup&lt;/s&gt;</dcterms:title>
    <rdf:type rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
  </rdf:Description>
</rdf:RDF>


Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/af37fbae/attachment-0002.html>

From hudsonr at us.ibm.com  Fri Aug 26 16:48:13 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Fri, 26 Aug 2011 16:48:13 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006DC2EF@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006DC2EF@ca.ibm.com>
Message-ID: <OF2E1EAFE2.B98E1BAD-ON852578F8.0071D7CE-852578F8.0072473A@us.ibm.com>

Either that validator is completely broken, or RDF/XML doesn't support
strings containing the character "<".

    <dc:title">World Wide Web &lt; Consortium</dc:title>

Jena will both produce and consume the alternate syntax I provided before.

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/26/2011 03:59 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you
include element content. If you use rdf:datatype then only character
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal"
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 03:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make
it easy to write literals of this kind"). Either way you write it, you end
up with the same statement. Two statements with the same subject, the same
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with
some sort of privileged XMLLiteral representation that couldn't written
out using any other RDF notation.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the
content a string that looks like XHTML, i.e. the


From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for


http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the


literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.


There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test


suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,


it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________




Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a


convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other


than at the model level), so I believe that one couldn't use it to produce


or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so


odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties


- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF


datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The


parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose


the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of


preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.


However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged


since it impairs interoperability.

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





Regards,
___________________________________________________________________________




Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this


thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the


use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use


of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use


a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral


in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other


XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And


note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"


syntax. And without that, I don't see a particular benefit in the stricter


XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a


consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that


"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),


I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of


view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation


it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons


(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all


consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________




Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact




[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format






_______________________________________________
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

_______________________________________________
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




_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From davidms at ca.ibm.com  Fri Aug 26 16:54:10 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 16:54:10 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
	<OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@LocalDomain>
Message-ID: <OF7C87C9F9.066C4358-ON852578F8.00728620-852578F8.0072D2F4@ca.ibm.com>


Dave Steinberg/Toronto/IBM wrote on 08/26/2011 04:37:55 PM:

> I had no problem parsing the following RDF/XML document (in which
> I've used my own HTML type) with the service:

Oops. I see that the validator is reporting a value with the &lt;s and
&gt;s intact. I believe that must be an error; it's not bothering to
interpret the XML entities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/350dc129/attachment-0002.html>

From ryman at ca.ibm.com  Fri Aug 26 16:58:10 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:58:10 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7C87C9F9.066C4358-ON852578F8.00728620-852578F8.0072D2F4@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>	<OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@LocalDomain>
	<OF7C87C9F9.066C4358-ON852578F8.00728620-852578F8.0072D2F4@ca.ibm.com>
Message-ID: <OF46D3DE46.982C94EE-ON852578F8.007323A0-852578F8.007331C1@ca.ibm.com>

Dave,

I believe it's just escaping them for output.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 04:54 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave Steinberg/Toronto/IBM wrote on 08/26/2011 04:37:55 PM:

> I had no problem parsing the following RDF/XML document (in which 
> I've used my own HTML type) with the service:

Oops. I see that the validator is reporting a value with the &lt;s and 
&gt;s intact. I believe that must be an error; it's not bothering to 
interpret the XML entities._______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Fri Aug 26 16:58:10 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:58:10 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
	<OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@ca.ibm.com>
Message-ID: <OFA3FECFEF.ECCAA761-ON852578F8.00724F0D-852578F8.007331BE@ca.ibm.com>

Dave,

It's good to know that the W3C RDF Validator accepted your private 
datatype. However, I haven't seen new datatypes being introduced by other 
vocabularies. If we do that it might reduce interoperablility.

Too bad Jena doesn't give you a DOM. Reparsing doesn't seem too 
inconvenient.

Omitting the datatypes because "we" know what they should be would reduce 
interoperability. We assume other applications will use our RDF resources, 
so we should make them explicit.

I agree the spec could be clearer. I believe Steve is improving it.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 04:39 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi again Arthur,

Lots of good points to address, so my responses are inline (also note that 
I wrote my previous, short reply to your later message in the middle of 
writing this longer one, so there may be a bit of overlap).

[Disclaimer: I realize I'm talking a lot about Jena in this message. 
That's because it's what I know. If there are other RDF toolkits in use, 
their behaviour is certainly relevant, too, and it would be good to hear 
from people with knowledge of them.]

Arthur Ryman/Toronto/IBM wrote on 08/25/2011 04:27:40 PM:
> 
> 1. XML Namespaces. 
> 
> The spec doesn't say "for XHTML, you need to insert an xmlns attribute 
for 
> http://www.w3.org/1999/xhtml" because that is part of the XHTML 
> standard, i.e. it's not XHTML unless the elements are in the XHTML 
namespace. 

I agree that XHTML does mean using the XHTML namespace, but I also believe 
it would have been helpful to underline that fact in the OSLC Core spec. 
Also, I still can't find a single example in the spec that actually shows 
markup in the value of an XMLLiteral-typed literal, which also would have 
been helpful. I notice that RTC doesn't use a namespace, so I suppose it 
wasn't obvious to them.

> 2. Jena
> 
> I loaded the sample RDF/XML  into Fuseki which uses Jena and it 
> produced the correct result. I assume the Jena API lets you get an 
> XML DOM from the literal value.

Thanks for this! I didn't know this, and it's reassuring. I was able to 
replicate this behaviour with pure Jena, simply by loading an RDF/XML 
resource containing your input and printing the type and lexical form of 
the literal:

Datatype: http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
Lexical form:  12345: <s xmlns="http://www.w3.org/1999/xhtml">Null pointer 
exception during startup</s>

Unfortunately, though, your assumption is not correct: Jena provides no 
access to underlying DOM. It appears that during parsing it computes the 
exclusive canonical form of the XML subset, as the RDF specs prescribe, 
and simply records that as the literal's lexical value. But, Jena's 
built-in XMLLiteral type support just uses java.lang.String as its value 
type. I was surprised when I first discovered that, too, but you can see 
for yourself in XMLLiteralType.parse().

> 3.  XHTML versus HTML
> 
> The primary reason is that RDF supports XHTML via the XMLLiteral 
> datatype. There is no parsing support for HTML built into RDF.

RDF doesn't require parsing support to use other datatypes, at least not 
in the abstract sense. Abstractly, a typed literal is just a datatype 
(identified by a URI) and a lexical form. Of course, it's very helpful in 
an implementation if you can automatically convert that to a more useful 
typed value (i.e. an Integer, Boolean, etc.), but that's purely a toolkit 
concern. Jena will support any datatype via its BaseDatatype.TypedValue 
wrapper type, but it's pluggable, so you can add specific parsing support 
for any type you wish.

> Another strong reason is that the syntax of HTML is very irregular 
> and hard to parse correctly - that is one of the reasons XML was 
> invented. This is very important from a security viewpoint. To guard
> against script injection attacks, you really should parse the input 
> and remove any <script> elements or Javascript attributes. Doing 
> that correctly for HTML requires a full HTML parser. On the other 
> hand, the XHTML is given to you as a DOM which you can easily 
> traverse or process using XSLT or XPATH.

But as you said, HTML Tidy can be used to parse HTML. You could even plug 
it in to Jena to do the parsing automatically for a defined datatype, 
which would be more convenient than the built in XMLLiteral support. Also, 
I really think that whether or not you need to parse and cleanse depends 
upon what you're doing with the data. It may not be necessary for an OSLC 
adapter that's merely passing along data from a trusted source, since it's 
incumbent upon a security-conscious client to do that, itself.

> 4. Datatypes
> 
> The specs do specify the datatypes for some properties. Look at the 
> Value-Type column of the tables, e.g. [1]. You need to include the 
> datatype explicitly for ints, dates, XML. etc. You specify that 
> using rdf:datatype in RDF/XML, or using ^^ in Turtle. 

Sorry if I wasn't clear. What I meant was that specs don't appear to say 
whether consumers and producers should use/expect typed literals or plain 
literals. I do see that the tables prescribe datatypes for the various 
literal-typed properties, but it doesn't say anywhere whether that means 
that typed literals should actually be used to specify those types, or 
that plain literals should be used (since those prescribed types are 
already presumed to be known).

> 5. Inventing new Datatypes
> 
> The RDF spec defines the XSD datatypes and the XMLLiteral datatype. 
> RDF parsers know how to parse those. If someone introduces a new 
> datatype URI, it could break parsers since they won't know how to 
> parse the contents. There is no standard way to define new datatypes. 
> 
> Try it with the RDF Validation service [2]

I had no problem parsing the following RDF/XML document (in which I've 
used my own HTML type) with the service:

<rdf:RDF
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:oslc_cm="http://open-services.net/ns/cm#" > 
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title rdf:datatype="
http://open-services.net/ns/core/types#HTML">12345: &lt;s&gt;Null pointer 
exception during startup&lt;/s&gt;</dcterms:title>
    <rdf:type rdf:resource="http://open-services.net/ns/cm#ChangeRequest
"/>
  </rdf:Description>
</rdf:RDF>


Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From davidms at ca.ibm.com  Fri Aug 26 17:31:11 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 17:31:11 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
Message-ID: <OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>


Hi Arthur,

Sorry, but I just don't agree. The two links you gave are both to the
RDF/XML spec, and they describe a special syntax for XMLLiteral-typed
literals and a general syntax for typed literals. They do not state that
the general syntax cannot be used for the case of XMLLiteral, and they
don't say anything that contradicts my understanding of the RDF abstract
data model.

Indeed, if you follow the "XML literals" link in Section 2.8, the RDF
Concepts spec defines XMLLiteral, like any other datatype, with a lexical
space, a value space and a mapping between the two. So, given any XML
value, what is to prevent you from using that mapping to compute a
corresponding lexical form, combining it with the datatype URI, and using
the ordinary literal notation (in any RDF concrete syntax)?

I just tried entering the following two RDF/XML documents into the
validation service:

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title rdf:parseType="Literal"
xmlns="http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception
during startup</s></dcterms:title>
  </rdf:Description>
</rdf:RDF>

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title
rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
12345: &lt;s xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception
during startup&lt;/s&gt;</dcterms:title>
  </rdf:Description>
</rdf:RDF>

It yielded exactly the same result in both cases:



I can also confirm Steve's claim that Jena can be configured to write out
exactly the same triples using either syntax.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                                                                
  From:       Arthur Ryman/Toronto/IBM                                                                                                          
                                                                                                                                                
  To:         Dave Steinberg/Toronto/IBM at IBMCA                                                                                                  
                                                                                                                                                
  Cc:         oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                  
                                                                                                                                                
  Date:       08/26/2011 03:58 PM                                                                                                               
                                                                                                                                                
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                                                   
                                                                                                                                                




Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you
include element content. If you use rdf:datatype then only character
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal"
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________
                                                                              
 Arthur Ryman                                                                 
                                                                              
 DE, PPM & Reporting Chief Architect                                          
                                                                              
 IBM Software, Rational                                                       
                                                                              
 Toronto Lab | +1-905-413-3077 (office) |                                     
 +1-416-939-5063 (mobile)                                                     
                                                                              





                                                                                                                                                
  From:       Dave Steinberg/Toronto/IBM at IBMCA                                                                                                  
                                                                                                                                                
  To:         oslc-core at open-services.net                                                                                                       
                                                                                                                                                
  Date:       08/26/2011 03:22 PM                                                                                                               
                                                                                                                                                
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                                                   
                                                                                                                                                
  Sent by:    oslc-core-bounces at open-services.net                                                                                               
                                                                                                                                                





Arthur,

I believe you're mistaken. I think that parseType="Literal" is just
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make
it easy to write literals of this kind"). Either way you write it, you end
up with the same statement. Two statements with the same subject, the same
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with
some sort of privileged XMLLiteral representation that couldn't written out
using any other RDF notation.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Inactive hide details for Arthur Ryman---08/26/2011 02:22:29 PM---Randy,
Your example makes the content a string that looks likArthur
Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the content a
string that looks like XHTML, i.e. the
                                                                           
                                                                           
 From:      Arthur Ryman/Toronto/IBM                                       
                                                                           
                                                                           
 To:        Randy Hudson/Raleigh/IBM at IBMUS                                 
                                                                           
                                                                           
 Cc:        Dave Steinberg <davidms at ca.ibm.com>,                           
            oslc-core at open-services.net,                                   
            oslc-core-bounces at open-services.net                            
                                                                           
                                                                           
 Date:      08/26/2011 02:22 PM                                            
                                                                           
                                                                           
 Subject:   Re: [oslc-core] OSLC Compact representation, titles with       
            markup                                                         
                                                                           





Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,

it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a

convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other

than at the model level), so I believe that one couldn't use it to produce

or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so

odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF

datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The

parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of

preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.

However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged

since it impairs interoperability.

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




Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the

use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use

of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use

a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral

in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other

XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And

note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"

syntax. And without that, I don't see a particular benefit in the stricter

XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a

consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that

"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),

I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of

view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation

it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons

(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all

consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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/20110826/ff138409/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12375707.gif
Type: image/gif
Size: 9285 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12992179.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0003.gif>

From davidms at ca.ibm.com  Fri Aug 26 17:35:00 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 17:35:00 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
Message-ID: <OFD7B386AA.44702968-ON852578F8.007682D9-852578F8.0076901F@ca.ibm.com>

> I can also confirm Steve's claim that Jena can be configured to
> write out exactly the same triples using either syntax.

Apologies: Randy's claim.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/945dd6af/attachment-0002.html>

From davidms at ca.ibm.com  Fri Aug 26 19:50:29 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 19:50:29 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF6FE7077F.DBDB00DB-ON852578F8.006F1789-852578F8.007083BA@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
	<OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
	<OF6FE7077F.DBDB00DB-ON852578F8.006F1789-852578F8.007083BA@LocalDomain>
Message-ID: <OFB3D589A2.890AE53F-ON852578F8.0081463F-852578F8.0082F769@ca.ibm.com>


Hi all,

I totally agree with Arthur on this. I think typed literals are a valuable
feature of RDF, and well worth using. As Arthur says, they allow a consumer
to make more sense of a literal value without already having a schema or
resource shape. Moreover, they allow you to use the same properties with
different types in a single resource. This is actually directly applicable
to the issue at hand with XHTML in compact rendering. Instead of defining
additional properties likes oslc:htmlEncodedTitle, we could define an HTML
type and use it as follows:

<rdf:RDF
    xmlns:oslc_types="http://open-services.net/ns/core/types#"
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title
rdf:datatype="http://open-services.net/ns/core/types#HTML">12345:
&lt;s&gt;Null pointer exception during startup&lt;/s&gt;</dcterms:title>
    <dcterms:title rdf:parseType="Literal">12345: <s
xmlns="http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>
  </rdf:Description>
</rdf:RDF>

This seems the more natural RDF approach to me, and you only need to define
one new type, which you could use with any number of properties.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                             
  From:       Arthur Ryman/Toronto/IBM                                                                       
                                                                                                             
  To:         Randy Hudson/Raleigh/IBM at IBMUS                                                                 
                                                                                                             
  Cc:         Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,                              
              oslc-core-bounces at open-services.net                                                            
                                                                                                             
  Date:       08/26/2011 04:28 PM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             





Randy,

For your second question/comment:

[Off topic]  I'm not sure I really see the benefit to including the
value's type in its serialized form in cases where only one datatype is
allowed.  It looks like bits of the "schema" get repeated over and over.

The reason is that there is no "schema" in the usual OO or database sense.
An RDF property can have any value and be repeated multiple times with
different values. In the case of OSLC, we try to say what to expect via
ResourceShapes, and we could "cast" plain literals to the correct data
value. However, we expect our RDF to be consumed by other applications and
so we need to include the datatypes to avoid ambiguity, e.g. is "true" a
boolean or a string?

I do agree that RDF looks very verbose with all the datatypes.

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get
jena to write out the property this way by setting an option on the
writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the
value's type in its serialized form in cases where only one datatype is
allowed.  It looks like bits of the "schema" get repeated over and over.

-Randy




From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)






From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,

it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a

convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other

than at the model level), so I believe that one couldn't use it to produce

or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so

odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF

datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The

parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of

preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.

However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged

since it impairs interoperability.

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




Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the

use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use

of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use

a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral

in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other

XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And

note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"

syntax. And without that, I don't see a particular benefit in the stricter

XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a

consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that

"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),

I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of

view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation

it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons

(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all

consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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/20110826/3a46fedf/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/3a46fedf/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/3a46fedf/attachment-0001.gif>

From sspeiche at us.ibm.com  Tue Aug 30 11:50:07 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 30 Aug 2011 11:50:07 -0400
Subject: [oslc-core] REMINDER: OSLC Core WG Meeting Day/Time Survey --
 Please Respond by Sept 1st
Message-ID: <OF5756EEFA.5CE220DA-ON852578FC.0056DC17-852578FC.0056FCA3@us.ibm.com>

If you have not done so, please fill out the survey.  I'm still expecting 
feedback from some people that I haven't seen.

Survey link: http://doodle.com/n5bef5gepvx2fhaw

Using dates 2 weeks from now just as an example.  Pick a day/time of week 
that works, even if it doesn't work for this one week.

Let me know if there are any questions.

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




From ryman at ca.ibm.com  Tue Aug 30 17:45:26 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 30 Aug 2011 17:45:26 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
Message-ID: <OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>

Dave,

My point was that when you use rdf:datatype, the content of the element 
must be a string, not XML. When you use rdf:parseType="Literal" the 
content is expected to be XML. In the RDF data model, the lexical space of 
XML consists of well-formed XML fragments, i.e. there is no escaping other 
than that required by XML.

You managed to get the rdf:datatype case to validate by escaping the XML 
markup, i.e. turning it into a string, which seems like unnecessary work 
if you already have an XML fragment.

BTW, I don't understand why the W3C RDF Validation service is displaying 
the XML content as escaped. That means the data is actually 
double-escaped. I'd be happier seeing plain text  N-Triples or Turtle.

It seems to me that since RDF/XML is well-formed XML, then the natural way 
to include XML literals is as XML, not as a string that contains escaped 
XML markup. However, I concede your point that in principle we don't need 
rdf:parseType="Literal"  if you are sure that we get exactly the same set 
of triples using just rdf:datatype. If so, you are correct in saying that 
rdf:parseType="Literal" is just syntactic sugar.

I see where you are going with this. You want OSLC to create a new 
datatype for HTML and you are demonstrating that rdf:datatype gives you 
the mechanism to do this. As I said before, creating a new datatype will 
limit interoperability since other processors will not know how to process 
the new datatype. There is no standard way to define the meaning of a new 
RDF datatype.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 05:31 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Sorry, but I just don't agree. The two links you gave are both to the 
RDF/XML spec, and they describe a special syntax for XMLLiteral-typed 
literals and a general syntax for typed literals. They do not state that 
the general syntax cannot be used for the case of XMLLiteral, and they 
don't say anything that contradicts my understanding of the RDF abstract 
data model.

Indeed, if you follow the "XML literals" link in Section 2.8, the RDF 
Concepts spec defines XMLLiteral, like any other datatype, with a lexical 
space, a value space and a mapping between the two. So, given any XML 
value, what is to prevent you from using that mapping to compute a 
corresponding lexical form, combining it with the datatype URI, and using 
the ordinary literal notation (in any RDF concrete syntax)?

I just tried entering the following two RDF/XML documents into the 
validation service:

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml
"> 12345: <s>Null pointer exception during startup</s></dcterms:title>
</rdf:Description>
</rdf:RDF>

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>
</rdf:Description>
</rdf:RDF>

It yielded exactly the same result in both cases:



I can also confirm Steve's claim that Jena can be configured to write out 
exactly the same triples using either syntax.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 03:58:51 PM---Dave, No, it's not just syntactic 
sugar. You need rdf:parseType="Literal" if you include element con


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/26/2011 03:58 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you 
include element content. If you use rdf:datatype then only character 
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal" 
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince 
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 


Dave Steinberg---08/26/2011 03:22:10 PM---Arthur, I believe you're 
mistaken. I think that parseType="Literal" is just


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/26/2011 03:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just 
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make 
it easy to write literals of this kind"). Either way you write it, you end 
up with the same statement. Two statements with the same subject, the same 
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same 
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with 
some sort of privileged XMLLiteral representation that couldn't written 
out using any other RDF notation.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the 
content a string that looks like XHTML, i.e. the

From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 


http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 


literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 


There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 


suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 


it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 



Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 


convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 


than at the model level), so I believe that one couldn't use it to produce 


or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 


odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 


- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 


datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 


parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 


the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 


preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 


However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 


since it impairs interoperability.

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




Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 


thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 


use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 


of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 


a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 


in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 


XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 


note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 


syntax. And without that, I don't see a particular benefit in the stricter 


XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 


consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 


"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 


I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 


view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 


it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 


(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 


consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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.n et/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






From sspeiche at us.ibm.com  Tue Aug 30 20:33:01 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 30 Aug 2011 20:33:01 -0400
Subject: [oslc-core] Fw: [oslc] New URL for OSLC Community Website
Message-ID: <OFB3F74D8C.C0547CD6-ON852578FD.0002F1D1-852578FD.00030641@us.ibm.com>

FYI for those who are not subscribed to the community list.  I recommend 
you weigh in on Core mail list with any spec issues/concerns.

> From: Steve K Speicher/Raleigh/IBM at IBMUS
> To: Kartik Kanakasabesan/Durham/IBM at IBMUS, 
> Cc: community at open-services.net
> Date: 08/30/2011 08:27 PM
> Subject: Re: [oslc] New URL for OSLC Community Website
> Sent by: community-bounces at open-services.net
> 
> +1
> 
> I think this is a good idea.  It has always been awkward to say "the 
OSLC 
> website" and then say "go to open-services.net", they don't exactly 
match 
> each other.  Looking at available domains (not oslc.net, oslc.org, 
> oslc.com) I saw oslc.co being available.  So I think it makes much 
easier 
> to direct people (without having to buy a domain from someone), to "the 
> OSLC website".
> 
> Regarding migration, I think Kartik has pointed out the 
open-services.net 
> is not going away.  The domain names defined in OSLC specs are not 
> changing.  Though, if accepted we could consider using the shorter "
> http://oslc.co" for the spec namespace base for further specs.
> 
> The redirect is active already, so you can go to http://oslc.co
> 
> Thanks,
> Steve Speicher | IBM Rational Software | (919) 254-0645
> 
> > From: Kartik Kanakasabesan/Durham/IBM at IBMUS
> > To: community at open-services.net, 
> > Date: 08/30/2011 02:45 PM
> > Subject: [oslc] New URL for OSLC Community Website
> > Sent by: community-bounces at open-services.net
> > 
> > Hi Folks, 
> >             Wanted to get feedback from the community on this issue. 
We 
> > would like to propose a new URL for the OSLC website, the proposed URL 

> is 
> > OSLC.co  instead of open-services.net. 
> > the .co domain name stands for community and falls in line with effort 

> we 
> > are pushing forward with OSLC. 
> > I would appreciate any thoughts/cocerns/comment on the matter. 
> > We would like to implement this domain change only if the community 
> agree's with it. 
> > Regards, 
> > Kartik _______________________________________________
> > Community mailing list
> > Community at open-services.net
> > http://open-services.net/mailman/listinfo/community_open-services.net
> 
> 
> _______________________________________________
> Community mailing list
> Community at open-services.net
> http://open-services.net/mailman/listinfo/community_open-services.net
> 




From ryman at ca.ibm.com  Wed Aug 31 09:17:38 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Wed, 31 Aug 2011 09:17:38 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
	<OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>
Message-ID: <OF4339B386.01E399CB-ON852578FD.0045DC2C-852578FD.0049075A@ca.ibm.com>

Dave/Randy,

Thx for persisting on this point. It turns out that the W3C RDF Validator 
is in fact displaying markup characters in strings wrong. It is escaping 
them. You can see the correct, unescaped, results by turning on the 
Advanced option of N-Triples output.

This discussion has made me realize that my suggested name for a new 
oslc:htmlEncodedTitle property is misleading. Encoding is only required 
when you put the triple in an XML document., e.g. the OSLC compact 
rendering resource  The encoding is removed by the parser and you end up 
with the unescaped string. Since we are defining RDF predicates, the 
reference to encoding is inappropriate because there is no encoding at the 
RDF value level.

We therefore have the following alternatives for markup in the title:

1. Use XML Literal datatype and XHTML content.
2. Define a new datatype for HTML
3. Define a new predicate for HTML titles, e.g. oslc:htmlTitle

Using HTML within the context of the UI preview is OK since the UI is 
expected to be a web UI and you'd just copy the string.

However, I think using HTML in RDF is not a good idea because all readers 
of the data would then have to cope with it, I mentioned that Tidy could 
be used by the writer of the data to convert it to XHTML. That does not 
mean this is practical for all readers of the data. In general, when you 
are designing a format for interoperability, you should convert diverse 
formats into one common format. We should therefore adopt XHTML as the one 
common format for marked up text interchange.

Recall that HTML is only one alternate format. We also have sources that 
produce rich text (RTF), and wiki text. Agreeing on XHTML is a useful 
simplification.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Dave Steinberg/Toronto/IBM at IBMCA
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/30/2011 05:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

My point was that when you use rdf:datatype, the content of the element 
must be a string, not XML. When you use rdf:parseType="Literal" the 
content is expected to be XML. In the RDF data model, the lexical space of 

XML consists of well-formed XML fragments, i.e. there is no escaping other 

than that required by XML.

You managed to get the rdf:datatype case to validate by escaping the XML 
markup, i.e. turning it into a string, which seems like unnecessary work 
if you already have an XML fragment.

BTW, I don't understand why the W3C RDF Validation service is displaying 
the XML content as escaped. That means the data is actually 
double-escaped. I'd be happier seeing plain text  N-Triples or Turtle.

It seems to me that since RDF/XML is well-formed XML, then the natural way 

to include XML literals is as XML, not as a string that contains escaped 
XML markup. However, I concede your point that in principle we don't need 
rdf:parseType="Literal"  if you are sure that we get exactly the same set 
of triples using just rdf:datatype. If so, you are correct in saying that 
rdf:parseType="Literal" is just syntactic sugar.

I see where you are going with this. You want OSLC to create a new 
datatype for HTML and you are demonstrating that rdf:datatype gives you 
the mechanism to do this. As I said before, creating a new datatype will 
limit interoperability since other processors will not know how to process 

the new datatype. There is no standard way to define the meaning of a new 
RDF datatype.

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 05:31 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Sorry, but I just don't agree. The two links you gave are both to the 
RDF/XML spec, and they describe a special syntax for XMLLiteral-typed 
literals and a general syntax for typed literals. They do not state that 
the general syntax cannot be used for the case of XMLLiteral, and they 
don't say anything that contradicts my understanding of the RDF abstract 
data model.

Indeed, if you follow the "XML literals" link in Section 2.8, the RDF 
Concepts spec defines XMLLiteral, like any other datatype, with a lexical 
space, a value space and a mapping between the two. So, given any XML 
value, what is to prevent you from using that mapping to compute a 
corresponding lexical form, combining it with the datatype URI, and using 
the ordinary literal notation (in any RDF concrete syntax)?

I just tried entering the following two RDF/XML documents into the 
validation service:

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml
"> 12345: <s>Null pointer exception during startup</s></dcterms:title>
</rdf:Description>
</rdf:RDF>

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>
</rdf:Description>
</rdf:RDF>

It yielded exactly the same result in both cases:



I can also confirm Steve's claim that Jena can be configured to write out 
exactly the same triples using either syntax.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 03:58:51 PM---Dave, No, it's not just syntactic 
sugar. You need rdf:parseType="Literal" if you include element con


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/26/2011 03:58 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you 

include element content. If you use rdf:datatype then only character 
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal" 
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince 
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 


Dave Steinberg---08/26/2011 03:22:10 PM---Arthur, I believe you're 
mistaken. I think that parseType="Literal" is just


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/26/2011 03:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just 
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make 
it easy to write literals of this kind"). Either way you write it, you end 

up with the same statement. Two statements with the same subject, the same 

predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same 
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with 
some sort of privileged XMLLiteral representation that couldn't written 
out using any other RDF notation.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the 
content a string that looks like XHTML, i.e. the

From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 



Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 



http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 



literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 



There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 



suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 



it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 




Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 



convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 



than at the model level), so I believe that one couldn't use it to produce 



or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 



odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 



- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 



datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 



parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 



the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 



preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 



However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 



since it impairs interoperability.

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





Regards, 
___________________________________________________________________________ 




Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 



thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 



use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 



of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 



a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 



in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 



XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 



note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 



syntax. And without that, I don't see a particular benefit in the stricter 



XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 



consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 



"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 



I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 



view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 



it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 



(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 



consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 




Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact




[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format






_______________________________________________
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

_______________________________________________
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




_______________________________________________
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.n et/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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Wed Aug 31 11:03:06 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Wed, 31 Aug 2011 11:03:06 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF4339B386.01E399CB-ON852578FD.0045DC2C-852578FD.0047AE42@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
	<OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>
	<OF4339B386.01E399CB-ON852578FD.0045DC2C-852578FD.0047AE42@LocalDomain>
Message-ID: <OF78BCA281.77E9C908-ON852578FD.005090E8-852578FD.0052AEFA@ca.ibm.com>

Dave/Randy,

I was wrong in saying that rdf:parseType="Literal" was required. I 
verified your statement that rdf:parseType="Literal" is syntactic sugar 
for a corresponding rdf:datatype attribute by using the jena.rdfcopy 
utility which converts RDF/XML to N-TRIPLE. The W3C RDF Validation service 
was erroneously escaping markup on output. The escaping is just an 
artifact of XML and is not part of the lexical space of RDF literal 
values. I am including an RDF/XML document and its N-TRIPLE equivalent.

Note that subjects 3 and 4 have identical objects.

RDF/XML

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dcterms="http://purl.org/dc/terms/">

<rdf:Description rdf:about="http://example.com/subject/1">
   <dcterms:title>1 &lt; 2</dcterms:title>
</rdf:Description>

<rdf:Description rdf:about="http://example.com/subject/2">
   <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml">This is 
<s>strikethrough</s>.</dcterms:title>
</rdf:Description>

<rdf:Description rdf:about="http://example.com/subject/3">
   <dcterms:title rdf:parseType="Literal">This is 
<s>strikethrough</s>.</dcterms:title>
</rdf:Description>

<rdf:Description rdf:about="http://example.com/subject/4">
   <dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">This is 
&lt;s&gt;strikethrough&lt;/s&gt;.</dcterms:title>
</rdf:Description>

</rdf:RDF>

N-TRIPLE

<http://example.com/subject/1> <http://purl.org/dc/terms/title> "1 < 2" .
<http://example.com/subject/2> <http://purl.org/dc/terms/title> "This is 
<s xmlns=\"http://www.w3.org/1999/xhtml\">strikethrough</s>."^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .
<http://example.com/subject/3> <http://purl.org/dc/terms/title> "This is 
<s>strikethrough</s>."^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .
<http://example.com/subject/4> <http://purl.org/dc/terms/title> "This is 
<s>strikethrough</s>."^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 



Arthur Ryman/Toronto/IBM wrote on 08/31/2011 09:02:56 AM:

> [image removed] 
> 
> Re: [oslc-core] OSLC Compact representation, titles with markup 
> 
> Arthur Ryman 
> 
> to:
> 
> Dave Steinberg
> 
> 08/31/2011 09:02 AM
> 
> Cc:
> 
> oslc-core, oslc-core-bounces
> 
> Dave/Randy,
> 
> Thx for persisting on this point. It turns out that the W3C RDF 
> Validator is in fact displaying markup characters in strings wrong. 
> It is escaping them. You can see the correct, unescaped, results by 
> turning on the Advanced option of N-Triples output.
> 




From spadgett at us.ibm.com  Sun Aug  7 13:00:51 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Sun, 7 Aug 2011 13:00:51 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
Message-ID: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>


I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact
[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




From spadgett at us.ibm.com  Sun Aug  7 13:06:11 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Sun, 7 Aug 2011 13:06:11 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
Message-ID: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@us.ibm.com>


Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact
[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




From hudsonr at us.ibm.com  Mon Aug  8 11:41:54 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Mon, 8 Aug 2011 11:41:54 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
Message-ID: <OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>

Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett/Durham/IBM                                                                                                                         |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net <oslc-core at open-services.net>                                                                                         |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA                                                                                     |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:06 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSLC Compact representation, titles with markup                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact
[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




From johnarwe at us.ibm.com  Fri Aug 12 07:42:41 2011
From: johnarwe at us.ibm.com (John Arwe)
Date: Fri, 12 Aug 2011 07:42:41 -0400
Subject: [oslc-core] JSON representation rules - typo
Message-ID: <OFC62D3251.D54117F2-ON852578EA.004000CA-852578EA.00405726@us.ibm.com>

http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_JSON 
says, in part:

1.0 For each property of a resource 
1.1 Add field to the resource's JSON object with name set to Prefixed Name 
of property 
1.1.1 If the property is specified as a single-valued property, then make 
field's value literal or JSON Object 
1.1.2 If the property is specified as a multi-valued property, then make 
field's value JSON Array 
1.2 Else if value-type is Literal 
1.2.1 Set field's value to string representation of property value 

Note the "Else if" at 1.2 without a matching "If".  Odds are it should 
read "1.2 If value-type", i.e. just remove the initial Else.


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/20110812/a0b504ca/attachment-0003.html>

From johnarwe at us.ibm.com  Fri Aug 12 09:47:31 2011
From: johnarwe at us.ibm.com (John Arwe)
Date: Fri, 12 Aug 2011 09:47:31 -0400
Subject: [oslc-core] Core 2.0 JSON Representation Guidelines - ambiguity in
 serialization of literals
Message-ID: <OF9958F3AB.828C0E72-ON852578EA.0045748F-852578EA.004BC51F@us.ibm.com>

At [1], under the rules to serialize each property, the prescription for 
Literal is to set the field's value equal to the "string representation" 
of the property value (pasted excerpt below, after [1]).  People are 
asking me if this means (for a value like 1.0 say in a property whose 
value-type is float), if that means 1.0 or "1.0".  Their interpretation of 
[1] is that "1.0" is the required output, implying that its JSON-type must 
be string; if the quotes were omitted, its JSON-type would be number, as I 
read [7].
In looking at the related examples and information about existing 
implementations (various flavors of "follow your nose" through the specs), 
I cannot answer this unambiguously using only the specs I have examined. 
Implementation samples suggest that the quotes are not required.  Here is 
a log of my travels; details for each are below.
[2] OSLC Core Specification:JSON Representation Examples appears to show 
only string and dateTime literals.  Since JSON does not have a native 
dateTime type, that document appears to be silent on this question. 
Recommendation: across the examples, cover each of the value-type 
possibilities.
[3] Open Services for Lifecycle Collaboration Core Specification Version 
2.0 Appendix A: Common Properties ; oslc:ResourceShape Resource lists 
(after the table) the valid value-type values, which includes 
integer/double and friends.  But no examples (they're in [2] in theory, 
fair enough if that were true).  Hmm.
[4] Wander over to CM examples; change requests at least have some 
booleans and dates, let's see how those are serialized in JSON as an 
indicator at least.  No such example.
[5] Remembering that CM defines a shape, and from [3] that shapes can have 
an integer maxsize and a boolean or two, try looking at the CM Shape. Only 
shown as an XML serialization :-(
[6] Having recently found out about the existence of a really good 
jazz.net article on RTC 3's CM usage, comb through that looking for what 
it tells me.  While this is not a guarantee of the spec's intent, it at 
least tells me what one implementation does, and since this implementation 
was one of those involved in spec convergence, it's a better-than-random, 
if not deterministic, example.  Pay-dirt at last, in Example 6 where it 
shows the serialization of oslc:responseInfo that includes 
"oslc:totalCount": 7, ...i.e., no quotes.
[6] Reading down further, I see "dc:identifier": 73, in Appendix B.  I'm 
"sure" identifier is a string, so why not "73"?  Checking in [3], indeed 
the value type of identifier is "string".  Now I'm really confused, or 
there is a bug in the article and/or the implementation from which the 
article was sourced.
[6] Futher down in Appendix B,  "rtc_cm:archived": false, which is 
consistent with totalCount (if the underlying intent is to use the JSON 
built-in types to the degree they match the value-type) but not with 
identifier.
[6] Yet further down, I find    "rtc_cm:correctedEstimate": null,   ... 
suggesting there may be yet another ambiguity in the serialization rules. 
I'm not sure what rule gets me to null, if all properties in RDF are 
optional.
Wander over to the QM spec [8] and its examples [9] + shapes [10].  Mostly 
strings, resources, and few dateTimes.  All the samples+shapes are XML.
Wander over to [11] Reqts Mgmt (since I thought that was implemented), but 
1.0 spec and wg page make me wonder.  Don't find any samples/shapes.
Am I missing something that explains why each of the examples above is 
either definitely right or definitely wrong, and similarly prescriptive 
information for all other value-types?



[1] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_JSON
These are the property rules referred to above. For each property: 
1.0 For each property of a resource 
1.1 Add field to the resource's JSON object with name set to Prefixed Name 
of property 
1.1.1 If the property is specified as a single-valued property, then make 
field's value literal or JSON Object 
1.1.2 If the property is specified as a multi-valued property, then make 
field's value JSON Array 
1.2 Else if value-type is Literal 
1.2.1 Set field's value to string representation of property value 
1.3 Else if value-type is Resource with representation of Reference
[2] http://open-services.net/bin/view/Main/OSLCCoreSpecJSONExamples
[3] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;table=up#oslc_ResourceShape_Resource
[4] http://open-services.net/bin/view/Main/CmSpecificationV2Samples
[5] http://open-services.net/bin/view/Main/CmSpecificationV2Shapes
[6] https://jazz.net/wiki/bin/view/Main/WorkItemAPIsForOSLCCM20
[7] http://tools.ietf.org/html/rfc4627
[8] http://open-services.net/bin/view/Main/QmSpecificationV2
[9] http://open-services.net/bin/view/Main/QmSpecificationV2Samples
[10] http://open-services.net/bin/view/Main/QmSpecificationV2Shapes
[11] http://open-services.net/bin/view/Main/RmHome

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/20110812/30fa7198/attachment-0003.html>

From nally at us.ibm.com  Fri Aug 12 12:04:32 2011
From: nally at us.ibm.com (Martin Nally)
Date: Fri, 12 Aug 2011 10:04:32 -0600
Subject: [oslc-core] AUTO: Martin Nally/Raleigh/IBM is out of the office
 until 06/26/2000. (returning 08/22/2011)
Message-ID: <OF216EF641.205C8B2E-ON872578EA.00584E8E-872578EA.00584E8E@us.ibm.com>


I am out of the office until 08/22/2011.

For urgent CTO office issues, contact Michelle Swenson who will determine
the best option


Note: This is an automated response to your message  "Oslc-Core Digest, Vol
19, Issue 2" sent on 8/12/2011 10:00:10.

This is the only notification you will receive while this person is away.




From aggarwav at us.ibm.com  Fri Aug 12 16:15:10 2011
From: aggarwav at us.ibm.com (Vijay Aggarwal)
Date: Fri, 12 Aug 2011 16:15:10 -0400
Subject: [oslc-core] AUTO: Vijay Aggarwal/Austin/IBM is on vacation
	(returning 08/17/2011)
Message-ID: <OF369C28C8.BF60AFA7-ON852578EA.006F40A4-852578EA.006F40A5@us.ibm.com>


I am out of the office until 08/17/2011.

I will be on vacation until August 17.  Please contact Chris Doan for
Service Desk topics, Daniel Wiegand for Service Catalog topics and James
Matlock for WellPoint topics.  For customer engagements, please contact Bob
Dunyak.

Thanks.
Vijay


Note: This is an automated response to your message  "Oslc-Core Digest, Vol
19, Issue 2" sent on 08/12/2011 12:00:10.

This is the only notification you will receive while this person is away.




From sspeiche at us.ibm.com  Mon Aug 22 10:14:06 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Mon, 22 Aug 2011 10:14:06 -0400
Subject: [oslc-core] JSON representation rules - typo
In-Reply-To: <OFC62D3251.D54117F2-ON852578EA.004000CA-852578EA.00405726@us.ibm.com>
References: <OFC62D3251.D54117F2-ON852578EA.004000CA-852578EA.00405726@us.ibm.com>
Message-ID: <OF6FBE34F4.2C77D0ED-ON852578F4.004E2444-852578F4.004E31FA@us.ibm.com>

Thanks John, I made the fix

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

> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 08/12/2011 09:24 AM
> Subject: [oslc-core] JSON representation rules - typo
> Sent by: oslc-core-bounces at open-services.net
> 
> 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?

> sortcol=table;up=#Guidelines_for_JSON says, in part: 
> 
> 1.0 For each property of a resource 
> 1.1 Add field to the resource's JSON object with name set to Prefixed 
Name 
> of property 
> 1.1.1 If the property is specified as a single-valued property, then 
make 
> field's value literal or JSON Object 
> 1.1.2 If the property is specified as a multi-valued property, then make 

> field's value JSON Array 
> 1.2 Else if value-type is Literal 
> 1.2.1 Set field's value to string representation of property value 
> Note the "Else if" at 1.2 without a matching "If".  Odds are it should 
read 
> "1.2 If value-type", i.e. just remove the initial Else. 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net




From ryman at ca.ibm.com  Mon Aug 22 16:10:19 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Mon, 22 Aug 2011 16:10:19 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@us.ibm.com>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@us.ibm.com>
Message-ID: <OFFB796645.6E9BAC4D-ON852578F4.006C9480-852578F4.006E7512@ca.ibm.com>

Sam,

You are correct. If you need to include formatting markup in text, the you 
should use the XML Literal datatype and put XHTML in it. XML Literal 
allows any well-formed  XML fragment, e.g. anything that is valid XML 
element content.

Your example is almost correct. It should also include the XHTML namespace 
declaration. A processor could assume that tags in the default namespace 
are XHTML. However, you should be explicit and include the namespace 
declaration:

  <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml ">12345: <s>Null pointer exception
during startup</s></dcterms:title>


A looked at the core spec [1] for dcterms:title and noticed another typo. 
The description description says:


Title of the resource represented as rich text in XHTML content. SHOULD 
include only content that is valid inside an XHTML <div> element. 

I think this was just copied from the description for dcterms:description, 
which SHOULD be like a <div>. A dcterms:title SHOULD be like a <span>, 
i.e.:

Title of the resource represented as rich text in XHTML content. SHOULD 
include only content that is valid inside an XHTML <span> element. 

[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:07 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Mon Aug 22 16:40:25 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Mon, 22 Aug 2011 16:40:25 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
Message-ID: <OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>

Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Mon Aug 22 16:55:36 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Mon, 22 Aug 2011 16:55:36 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
	<OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
Message-ID: <OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>

Randy,

I think example [3] is wrong. If the datatype is plain text then you 
should not assume it contains encoded HTML. If you need to include markup 
then you should use XML Literal datatype, and use XHTML content. This is 
described in the core spec [4] which gives guidance for putting markup in 
dcterms:title and dcterms:description.

[4] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Randy Hudson <hudsonr at us.ibm.com>
To:
Samuel Padgett <spadgett at us.ibm.com>, Steve K Speicher 
<sspeiche at us.ibm.com>
Cc:
Adam Archer/Toronto/IBM at IBMCA, "oslc-core at open-services.net" 
<oslc-core at open-services.net>
Date:
08/08/2011 11:54 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be 
wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett/Durham/IBM                              |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net <oslc-core at open-services.net>            |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA           
                   |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:06 PM                        |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSLC Compact representation, titles with markup         |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From agarcher at ca.ibm.com  Mon Aug 22 17:00:05 2011
From: agarcher at ca.ibm.com (Adam Archer)
Date: Mon, 22 Aug 2011 17:00:05 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
Message-ID: <OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>

The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at).

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From:   Arthur Ryman/Toronto/IBM
To:     Samuel Padgett <spadgett at us.ibm.com>
Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110822/2dae579d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110822/2dae579d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110822/2dae579d/attachment-0001.gif>

From davidms at ca.ibm.com  Tue Aug 23 00:02:44 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Tue, 23 Aug 2011 00:02:44 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
Message-ID: <OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>


Hi all,

I've been following this thread with interest, as it touches on some of the
more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated as
a simple string or as HTML content. And that's the very thing that typed
literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type is
supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types in
both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than XMLLiteral
eliminates the "benefit" of the special rdf:parseType="Literal" syntax. And
without that, I don't see a particular benefit in the stricter XHTML
syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I believe
that, strictly, the XHTML namespace is required for the elements to be
valid XHTML. But I found no hint of this in the spec or any examples, and
certainly RTC doesn't do this (I haven't checked other providers).
Moreover, I believe it's also a worse approach, since there's no guarantee
that your RDF runtime of choice will give you access to namespaces declared
on the property element (I don't believe Jena does), and detecting a
namespace inside the element content would require actually parsing the
value as XML. If all you want to do is pass markup along for display in a
browser, it would be unfortunate to have to actually parse the content to
determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably just
as good as, if not better than, XHTML. Rather than worrying about whether
the content is well-formed XML, it's probably sufficient to just give it to
the browser and see what it can do with it. I would assert that "something
a browser can render" has been the working definition of HTML for a good
number of years now, while XHTML has largely faded in importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it via
OSLC. Likewise, a consumer may use a rich text control that yields HTML.
Generalized parsing of HTML for conversion to XHTML is non-trivial, and it
seems unfortunate to impose that conversion task onto everyone, just so
that we can use rdf:parseType="Literal" in RDF/XML and avoid applying
normal XML encoding to markup content (of course, some encoding will likely
be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if they
all do make perfect sense (and I'm not necessarily claiming they do), I
realize we may be well past the point of being able to act on them. Still,
I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property needed
to change. This is a related, but separate, topic, which I'd be thrilled to
discuss further, but I don't want to open too many cans of worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                             
  From:       Adam Archer/Toronto/IBM at IBMCA                                                                  
                                                                                                             
  To:         Arthur Ryman/Toronto/IBM at IBMCA                                                                 
                                                                                                             
  Cc:         "oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson                      
              <hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net                                      
                                                                                                             
  Date:       08/22/2011 06:20 PM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             
  Sent by:    oslc-core-bounces at open-services.net                                                            
                                                                                                             





The big concern to me is not the ability to process the RDF/XML with XPath,
it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply taking
the content of the attribute, decoding it (which browsers are very good at)
and slapping the result into the dom (which browsers are also very good
at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I don't
even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine what
the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From:        Arthur Ryman/Toronto/IBM
To:        Samuel Padgett <spadgett at us.ibm.com>
Cc:        Adam Archer/Toronto/IBM at IBMCA, Randy Hudson
<hudsonr at us.ibm.com>, "oslc-core at open-services.net"
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net
Date:        08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one point
we tried to define an OSLC-variant of RDF/XML that looked like "normal"
XML. However, we abandonned that and now require support for generic
RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an RDF
toolkit like Jena.

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                   Twitter | Facebook | YouTube   
                                                                                
                                                                                
                                                                                





                                                                           
 From:    Samuel Padgett <spadgett at us.ibm.com>                             
                                                                           
 To:      "oslc-core at open-services.net" <oslc-core at open-services.net>      
                                                                           
 Cc:      Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
                                                                           
                                                                           
 Date:    08/07/2011 01:01 PM                                              
                                                                           
 Subject: [oslc-core] OSLC Compact representation, titles with markup      
                                                                           
                                                                           
 Sent by: oslc-core-bounces at open-services.net                              
                                                                           
                                                                           







I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

 <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

 <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

 <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110823/42ed4e89/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19967617.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 19394555.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/42ed4e89/attachment-0003.gif>

From sspeiche at us.ibm.com  Tue Aug 23 09:13:55 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 23 Aug 2011 09:13:55 -0400
Subject: [oslc-core] REMINDER: Core WG Meeting tomorrow (Wed Aug 24) 10:00 ET
Message-ID: <OFE7F482C2.46469320-ON852578F5.00472DA8-852578F5.0048AF8A@us.ibm.com>

Date: Wednesday, 24 August 2011
Time: 10:00 AM Eastern

Agenda:
 - General news
 - Time / date of meeting (some have hard conflict)
 - 2.0 spec issues
  - ui preview label encoding
  - json rep ambiguities
 - 3.0 themes, priorities and timeline development

http://open-services.net/bin/view/Main/OslcCoreMeetings

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




From ryman at ca.ibm.com  Tue Aug 23 10:10:06 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 23 Aug 2011 10:10:06 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
Message-ID: <OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DD584@ca.ibm.com>

Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 
datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 
parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 
preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 
However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 
since it impairs interoperability.

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

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/23/2011 12:06 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 
use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 
of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 
a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 
in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 
XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 
note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 
syntax. And without that, I don't see a particular benefit in the stricter 
XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 
consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 
"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 
I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do


From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Tue Aug 23 10:40:18 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 23 Aug 2011 10:40:18 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
Message-ID: <OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.00509995@ca.ibm.com>

Adam,

Your argument for escaping HTML is based purely on the use case of compact 
rendering. However, the OSLC specs are designed to enable many other use 
cases and to promote general interoperability among different tools.

The OSLC core spec provides guidelines for the use of some common RDF 
properties, including those from the Dublin Core. [1] dcterms:title and 
dcterms:description in general contain text that may include formatting 
information. There were several candidates for syntax - HTML, Wiki, RTF. 
The RDF spec contains the means for including XML literals, and XHTML is 
the W3C standard for formatted text. All the other text formats are 
convertible to XHTML. It was therefore chosen as the recommended way to 
package rich text.

The historical design of Jazz compact rendering is optimized for 
consumption by web browsers. However, the RDF plain text datatype does NOT 
imply that the text is HTML encoded. Another processor would be justified 
in displaying the verbatim encoding.

However, for the case of OSLC preview, I see no reason why the text 
couldn't be encoded, but it should be put in a property that makes that 
clear, e.g. oslc:htmlEncodedTitle.

FYI, I work on Focal Point and its REST API provides both a plain text and 
a marked up text version of some attributes.

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

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Adam Archer/Toronto/IBM
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Samuel Padgett <spadgett at us.ibm.com>, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:
08/22/2011 05:00 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at).

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:   Arthur Ryman/Toronto/IBM
To:     Samuel Padgett <spadgett at us.ibm.com>
Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net







From spadgett at us.ibm.com  Tue Aug 23 11:11:38 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Tue, 23 Aug 2011 11:11:38 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
Message-ID: <OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@us.ibm.com>

Hi, Arthur. Thanks for the answers. It clears some things up for me.

Arthur Ryman <ryman at ca.ibm.com> wrote on 08/22/2011 04:40:25 PM:

> I don't think problems using XPath are a valid reason to encode markup
> since RDF/XML itselt is very difficult to process using XPath. At one
> point we tried to define an OSLC-variant of RDF/XML that looked like
> "normal" XML. However, we abandonned that and now require support for
> generic RDF/XML.

To make sure I understand: By generic RDF/XML, you are talking about what
the spec calls "constrained RDF/XML" in Appendix B, right? [1]

> The are many equivalent ways to represent a given set of triples in
> RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
> XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
> RDF toolkit like Jena.

This makes sense, and I agree. But for me it also raises a few questions:

- Do we need a JSON Compact representation for consumers who don't use an
RDF library? This is one of the few resources in OSLC that doesn't have a
JSON representation, and it seems natural since so often the consumer here
is a web client.

- Should we define a "constrained RDF/XML" representation if our
recommendation is to use an RDF toolkit anyway? JSON might be a reasonable
alternative for those who don't want RDF/XML.

Best Regards,
Sam

[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_application_xml




From hudsonr at us.ibm.com  Tue Aug 23 10:36:19 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Tue, 23 Aug 2011 10:36:19 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
	<OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
	<OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>
Message-ID: <OF9BE55011.703713F3-ON852578F5.004E4930-852578F5.00503AAD@us.ibm.com>

I don't think the value's datatype is the same as the parseType.  The data
is [X]HTML, no matter what.  It is typically encoded, because that's the
way you store a value in XML, and as long as you follow standard XML
practice, using XPath to extract it has been pretty straightforward.  For
better or worse, RDF/XML supports the use of parseType, but many OSLC
consumers out there today are not going to handle documents that chose to
use parseType.

Also, the value really needs to be a snippet of HTML, not XHTML.  Existing
consumers are taking the value as if it were HTML and putting (after
sanitizing) it directly in an existing HTML page.  I'm sure there would be
problems consuming an XHTML snippet, for example, one that chose to assign
the XHTML to a non-default namespace.

FWIW, there are other places where OSLC deviates from what RDF/XML allows.
e.g., requiring the use of absolute URIs.

-Randy



|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" <oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel       |
  |Padgett/Durham/IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS                                                                                      |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/22/2011 04:55 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Randy,

I think example [3] is wrong. If the datatype is plain text then you
should not assume it contains encoded HTML. If you need to include markup
then you should use XML Literal datatype, and use XHTML content. This is
described in the core spec [4] which gives guidance for putting markup in
dcterms:title and dcterms:description.

[4]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties


Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube







From:
Randy Hudson <hudsonr at us.ibm.com>
To:
Samuel Padgett <spadgett at us.ibm.com>, Steve K Speicher
<sspeiche at us.ibm.com>
Cc:
Adam Archer/Toronto/IBM at IBMCA, "oslc-core at open-services.net"
<oslc-core at open-services.net>
Date:
08/08/2011 11:54 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be
wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |Samuel Padgett/Durham/IBM                              |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| To:        |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |oslc-core at open-services.net <oslc-core at open-services.net>            |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Cc:        |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA
                   |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Date:      |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |08/07/2011 01:06 PM                        |

>--------------------------------------------------------------------------------------------------------------------------------------------------|

|------------>
| Subject:   |
|------------>

>--------------------------------------------------------------------------------------------------------------------------------------------------|

  |OSLC Compact representation, titles with markup         |

>--------------------------------------------------------------------------------------------------------------------------------------------------|





Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net








From agarcher at ca.ibm.com  Tue Aug 23 11:35:57 2011
From: agarcher at ca.ibm.com (Adam Archer)
Date: Tue, 23 Aug 2011 11:35:57 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.004F6D01@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
	<OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.004F6D01@LocalDomain>
Message-ID: <OFD60830E3.3177897D-ON852578F5.00553E12-852578F5.0055B063@ca.ibm.com>

Arthur,

I understand that OSLC is taking a larger problem domain into account when 
defining syntax and data types, but I'm not arguing about that. I'm 
arguing that in the specific case of the compact spec, it makes it much 
less consumable. Generalizing is not always a good thing if it makes life 
more difficult for some of the cases. Perhaps what you are suggesting with 
the oslc:htmlEncodedTitle idea is the right way to address this, but all 
I'm advocating is that we not make this more complicated for consumers 
than it has been for the last 3 years. If that means a change to the spec, 
so be it.

Adam Archer
Jazz Developer
IBM Toronto Lab



From:   Arthur Ryman/Toronto/IBM
To:     Adam Archer/Toronto/IBM at IBMCA
Cc:     Randy Hudson <hudsonr at us.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel 
Padgett <spadgett at us.ibm.com>
Date:   08/23/2011 10:40 AM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Adam,

Your argument for escaping HTML is based purely on the use case of compact 
rendering. However, the OSLC specs are designed to enable many other use 
cases and to promote general interoperability among different tools.

The OSLC core spec provides guidelines for the use of some common RDF 
properties, including those from the Dublin Core. [1] dcterms:title and 
dcterms:description in general contain text that may include formatting 
information. There were several candidates for syntax - HTML, Wiki, RTF. 
The RDF spec contains the means for including XML literals, and XHTML is 
the W3C standard for formatted text. All the other text formats are 
convertible to XHTML. It was therefore chosen as the recommended way to 
package rich text.

The historical design of Jazz compact rendering is optimized for 
consumption by web browsers. However, the RDF plain text datatype does NOT 
imply that the text is HTML encoded. Another processor would be justified 
in displaying the verbatim encoding.

However, for the case of OSLC preview, I see no reason why the text 
couldn't be encoded, but it should be put in a property that makes that 
clear, e.g. oslc:htmlEncodedTitle.

FYI, I work on Focal Point and its REST API provides both a plain text and 
a marked up text version of some attributes.

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

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Adam Archer/Toronto/IBM
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Samuel Padgett <spadgett at us.ibm.com>, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:
08/22/2011 05:00 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at).

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:   Arthur Ryman/Toronto/IBM
To:     Samuel Padgett <spadgett at us.ibm.com>
Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net
Date:   08/22/2011 04:40 PM
Subject:        Re: [oslc-core] OSLC Compact representation, titles with 
markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube








From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net




I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110823/9ba80559/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/9ba80559/attachment-0003.gif>

From sspeiche at us.ibm.com  Tue Aug 23 12:09:21 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 23 Aug 2011 12:09:21 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@us.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
	<OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@us.ibm.com>
Message-ID: <OF44A54CE2.FBFEAA8D-ON852578F5.00584E63-852578F5.0058BF38@us.ibm.com>

One thing I was going to point out, that the only representation supported 
is XML for Compact (not RDF/XML or JSON).

"The Compact representation MUST be in the XML format described in this 
document" 

I've queued this discussion as an issue to be discussed in Core WG

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


oslc-core-bounces at open-services.net wrote on 08/23/2011 11:11:38 AM:

> From: Samuel Padgett/Durham/IBM at IBMUS
> To: Arthur Ryman <ryman at ca.ibm.com>, 
> Cc: Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-
> core at open-services.net>, Randy Hudson/Raleigh/IBM at IBMUS, oslc-core-
> bounces at open-services.net
> Date: 08/23/2011 11:24 AM
> Subject: Re: [oslc-core] OSLC Compact representation, titles with markup
> Sent by: oslc-core-bounces at open-services.net
> 
> Hi, Arthur. Thanks for the answers. It clears some things up for me.
> 
> Arthur Ryman <ryman at ca.ibm.com> wrote on 08/22/2011 04:40:25 PM:
> 
> > I don't think problems using XPath are a valid reason to encode markup
> > since RDF/XML itselt is very difficult to process using XPath. At one
> > point we tried to define an OSLC-variant of RDF/XML that looked like
> > "normal" XML. However, we abandonned that and now require support for
> > generic RDF/XML.
> 
> To make sure I understand: By generic RDF/XML, you are talking about 
what
> the spec calls "constrained RDF/XML" in Appendix B, right? [1]
> 
> > The are many equivalent ways to represent a given set of triples in
> > RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
> > XQuery to process RDF/XML. The safe way to process RDF/XML is to use 
an
> > RDF toolkit like Jena.
> 
> This makes sense, and I agree. But for me it also raises a few 
questions:
> 
> - Do we need a JSON Compact representation for consumers who don't use 
an
> RDF library? This is one of the few resources in OSLC that doesn't have 
a
> JSON representation, and it seems natural since so often the consumer 
here
> is a web client.
> 
> - Should we define a "constrained RDF/XML" representation if our
> recommendation is to use an RDF toolkit anyway? JSON might be a 
reasonable
> alternative for those who don't want RDF/XML.
> 
> Best Regards,
> Sam
> 
> [1]
> 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?

> sortcol=table;up=#Guidelines_for_application_xml
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net




From spadgett at us.ibm.com  Tue Aug 23 15:14:01 2011
From: spadgett at us.ibm.com (Samuel Padgett)
Date: Tue, 23 Aug 2011 15:14:01 -0400
Subject: [oslc-core] Minor problem in JSON Service Provider Resource example
Message-ID: <OF668F4399.44D2378F-ON852578F5.0068F15E-852578F5.0069B312@us.ibm.com>


Minor problem in the JSON Service Provider Resource example [1]: It looks
like 'service' should be 'oslc:service', and the value should be a JSON
array rather than a JSON object since it occurs 'one-or-many' [2].

- Best Regards, Sam

[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecJSONExamples?sortcol=table;up=#Service_Provider_Resource
[2]
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Service_Provider_Resources




From ryman at ca.ibm.com  Tue Aug 23 15:14:51 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 23 Aug 2011 15:14:51 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFD60830E3.3177897D-ON852578F5.00553E12-852578F5.00559CCB@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00734F25@LocalDomain>
	<OF78087452.D5D106BC-ON852578F5.004DF801-852578F5.004F6D01@LocalDomain>
	<OFD60830E3.3177897D-ON852578F5.00553E12-852578F5.00559CCB@LocalDomain>
Message-ID: <OF9A5008D5.3F2D2835-ON852578F5.006973E3-852578F5.0069BAD4@ca.ibm.com>


Adam,

Yes, I am suggesting that when people use dcterms:title they represent
markup via XML Literal rather than HTML encoding. It think it would be
cleaner to use a special purpose property for literals that were encoded
HTML, e.g. oslc:htmlEncodedTitle.

Regards,
___________________________________________________________________________
                                                                               
 Arthur Ryman                                                                  
                                                                               
 DE, PPM Chief Architect                                                       
                                                                               
 IBM Software, Rational                                                        
                                                                               
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |  
                                                                      YouTube  
                                                                               
                                                                               
                                                                               




|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer/Toronto/IBM                                                                                                                           |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman/Toronto/IBM at IBMCA                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson <hudsonr at us.ibm.com>, "oslc-core at open-services.net" <oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel       |
  |Padgett <spadgett at us.ibm.com>                                                                                                                     |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/23/2011 11:35 AM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Arthur,

I understand that OSLC is taking a larger problem domain into account when
defining syntax and data types, but I'm not arguing about that. I'm arguing
that in the specific case of the compact spec, it makes it much less
consumable. Generalizing is not always a good thing if it makes life more
difficult for some of the cases. Perhaps what you are suggesting with the
oslc:htmlEncodedTitle idea is the right way to address this, but all I'm
advocating is that we not make this more complicated for consumers than it
has been for the last 3 years. If that means a change to the spec, so be
it.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:	Arthur Ryman/Toronto/IBM
To:	Adam Archer/Toronto/IBM at IBMCA
Cc:	Randy Hudson <hudsonr at us.ibm.com>,
            "oslc-core at open-services.net" <oslc-core at open-services.net>,
            oslc-core-bounces at open-services.net, Samuel Padgett
            <spadgett at us.ibm.com>
Date:	08/23/2011 10:40 AM
Subject:	Re: [oslc-core] OSLC Compact representation, titles with markup


Adam,

Your argument for escaping HTML is based purely on the use case of compact
rendering. However, the OSLC specs are designed to enable many other use
cases and to promote general interoperability among different tools.

The OSLC core spec provides guidelines for the use of some common RDF
properties, including those from the Dublin Core. [1] dcterms:title and
dcterms:description in general contain text that may include formatting
information. There were several candidates for syntax - HTML, Wiki, RTF.
The RDF spec contains the means for including XML literals, and XHTML is
the W3C standard for formatted text. All the other text formats are
convertible to XHTML. It was therefore chosen as the recommended way to
package rich text.

The historical design of Jazz compact rendering is optimized for
consumption by web browsers. However, the RDF plain text datatype does NOT
imply that the text is HTML encoded. Another processor would be justified
in displaying the verbatim encoding.

However, for the case of OSLC preview, I see no reason why the text
couldn't be encoded, but it should be put in a property that makes that
clear, e.g. oslc:htmlEncodedTitle.

FYI, I work on Focal Point and its REST API provides both a plain text and
a marked up text version of some attributes.

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

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |   
                                                                      YouTube   
                                                                                
                                                                                
                                                                                





|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer/Toronto/IBM                                                                                                                           |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman/Toronto/IBM at IBMCA                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett <spadgett at us.ibm.com>, Randy Hudson <hudsonr at us.ibm.com>, "oslc-core at open-services.net" <oslc-core at open-services.net>,             |
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/22/2011 05:00 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




The big concern to me is not the ability to process the RDF/XML with XPath,
it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply taking
the content of the attribute, decoding it (which browsers are very good at)
and slapping the result into the dom (which browsers are also very good
at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I don't
even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine what
the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab




From:	Arthur Ryman/Toronto/IBM
To:	Samuel Padgett <spadgett at us.ibm.com>
Cc:	Adam Archer/Toronto/IBM at IBMCA, Randy Hudson
            <hudsonr at us.ibm.com>, "oslc-core at open-services.net"
            <oslc-core at open-services.net>,
            oslc-core-bounces at open-services.net
Date:	08/22/2011 04:40 PM
Subject:	Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one point
we tried to define an OSLC-variant of RDF/XML that looked like "normal"
XML. However, we abandonned that and now require support for generic
RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an RDF
toolkit like Jena.

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |   
                                                                      YouTube   
                                                                                
                                                                                
                                                                                





|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett <spadgett at us.ibm.com>                                                                                                              |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"oslc-core at open-services.net" <oslc-core at open-services.net>                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:01 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |[oslc-core] OSLC Compact representation, titles with markup                                                                                       |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|






I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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/20110823/ebec2025/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12845780.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12047798.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110823/ebec2025/attachment-0003.gif>

From davidms at ca.ibm.com  Wed Aug 24 15:01:19 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Wed, 24 Aug 2011 15:01:19 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
Message-ID: <OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>


Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a
convenience, but only if tools supported that. As far as I could find, Jena
provides no fine-grained access to namespace declarations (i.e. other than
at the model level), so I believe that one couldn't use it to produce or
consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. That
was very helpful for me. But I must admit, I'm still left wondering what
makes XHTML superior to HTML for interchanging formatted text, especially
in light of the compact representation example and my own experiences,
where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so
odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of this
is acknowledged or explained anywhere. It looks like using a typed literal
in this one case is accepted merely as a requirement to benefit from the
prettier RDF/XML syntax for XML content. However, I view things completely
in the opposite light. To me, typed literals are a powerful benefit of RDF.
You can use a typed literal to decide how to handle a literal value,
without looking at the value itself, but that advantage is lost without a
sufficiently specific type. Thus, I don't understand how defining and using
a new RDF datatype to identify something as widely recognized and
understood as HTML would impair interoperability. I think it would do the
opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                             
  From:       Arthur Ryman/Toronto/IBM                                                                       
                                                                                                             
  To:         Dave Steinberg/Toronto/IBM at IBMCA                                                               
                                                                                                             
  Cc:         oslc-core at open-services.net, oslc-core-bounces at open-services.net                               
                                                                                                             
  Date:       08/23/2011 10:09 AM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             




Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF
datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The
parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. There
are converter from HTML to XHTML, e.g. Tidy. However, in the case of
preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.
However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF etc.
would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged
since it impairs interoperability.

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

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                           Twitter | Facebook |   
                                                                      YouTube   
                                                                                
                                                                                
                                                                                





                                                                                                             
  From:       Dave Steinberg/Toronto/IBM at IBMCA                                                               
                                                                                                             
  To:         oslc-core at open-services.net                                                                    
                                                                                                             
  Date:       08/23/2011 12:06 AM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             
  Sent by:    oslc-core-bounces at open-services.net                                                            
                                                                                                             





Hi all,

I've been following this thread with interest, as it touches on some of the
more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated as
a simple string or as HTML content. And that's the very thing that typed
literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type is
supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types in
both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than XMLLiteral
eliminates the "benefit" of the special rdf:parseType="Literal" syntax. And
without that, I don't see a particular benefit in the stricter XHTML
syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I believe
that, strictly, the XHTML namespace is required for the elements to be
valid XHTML. But I found no hint of this in the spec or any examples, and
certainly RTC doesn't do this (I haven't checked other providers).
Moreover, I believe it's also a worse approach, since there's no guarantee
that your RDF runtime of choice will give you access to namespaces declared
on the property element (I don't believe Jena does), and detecting a
namespace inside the element content would require actually parsing the
value as XML. If all you want to do is pass markup along for display in a
browser, it would be unfortunate to have to actually parse the content to
determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably just
as good as, if not better than, XHTML. Rather than worrying about whether
the content is well-formed XML, it's probably sufficient to just give it to
the browser and see what it can do with it. I would assert that "something
a browser can render" has been the working definition of HTML for a good
number of years now, while XHTML has largely faded in importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it via
OSLC. Likewise, a consumer may use a rich text control that yields HTML.
Generalized parsing of HTML for conversion to XHTML is non-trivial, and it
seems unfortunate to impose that conversion task onto everyone, just so
that we can use rdf:parseType="Literal" in RDF/XML and avoid applying
normal XML encoding to markup content (of course, some encoding will likely
be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if they
all do make perfect sense (and I'm not necessarily claiming they do), I
realize we may be well past the point of being able to act on them. Still,
I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property needed
to change. This is a related, but separate, topic, which I'd be thrilled to
discuss further, but I don't want to open too many cans of worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Inactive hide details for Adam Archer---08/22/2011 06:20:05 PM---The big
concern to me is not the ability to process the RDF/XMAdam
Archer---08/22/2011 06:20:05 PM---The big concern to me is not the ability
to process the RDF/XML with XPath, it's the ability to do
                                                                           
                                                                           
 From:    Adam Archer/Toronto/IBM at IBMCA                                    
                                                                           
                                                                           
 To:      Arthur Ryman/Toronto/IBM at IBMCA                                   
                                                                           
                                                                           
 Cc:      "oslc-core at open-services.net" <oslc-core at open-services.net>,     
          Randy Hudson <hudsonr at us.ibm.com>,                               
          oslc-core-bounces at open-services.net                              
                                                                           
                                                                           
 Date:    08/22/2011 06:20 PM                                              
                                                                           
                                                                           
 Subject: Re: [oslc-core] OSLC Compact representation, titles with markup  
                                                                           
                                                                           
 Sent by: oslc-core-bounces at open-services.net                              
                                                                           





The big concern to me is not the ability to process the RDF/XML with XPath,
it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply taking
the content of the attribute, decoding it (which browsers are very good at)
and slapping the result into the dom (which browsers are also very good
at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I don't
even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine what
the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one point
we tried to define an OSLC-variant of RDF/XML that looked like "normal"
XML. However, we abandonned that and now require support for generic
RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an RDF
toolkit like Jena.

Regards,
___________________________________________________________________________
                                                                                
 Arthur Ryman                                                                   
                                                                                
 DE, PPM Chief Architect                                                        
                                                                                
 IBM Software, Rational                                                         
                                                                                
 Toronto Lab | +1-905-413-3077                   Twitter | Facebook | YouTube   
                                                                                
                                                                                
                                                                                




                                                                           
 From:   Samuel Padgett <spadgett at us.ibm.com>                              
                                                                           
 To:     "oslc-core at open-services.net" <oslc-core at open-services.net>       
                                                                           
 Cc:     Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>  
                                                                           
 Date:   08/07/2011 01:01 PM                                               
                                                                           
 Subject [oslc-core] OSLC Compact representation, titles with markup       
 :                                                                         
                                                                           
 Sent    oslc-core-bounces at open-services.net                               
 by:                                                                       
                                                                           







I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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

_______________________________________________
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/20110824/f29be9da/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16248338.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16539910.gif
Type: image/gif
Size: 9590 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110824/f29be9da/attachment-0003.gif>

From sspeiche at us.ibm.com  Wed Aug 24 15:13:24 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Wed, 24 Aug 2011 15:13:24 -0400
Subject: [oslc-core] OSLC Core WG Minutes: August 24, 2011
Message-ID: <OF0BB3350E.4EE7A509-ON852578F6.0069422A-852578F6.00699900@us.ibm.com>

http://open-services.net/bin/view/Main/OslcCoreMeeting20110824

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




From sspeiche at us.ibm.com  Wed Aug 24 15:41:11 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Wed, 24 Aug 2011 15:41:11 -0400
Subject: [oslc-core] OSLC Core WG Meeting Day/Time Survey -- Please Respond
Message-ID: <OFFFB1A464.E6A3D81D-ON852578F6.006B6AC9-852578F6.006C2440@us.ibm.com>

Survey link: http://doodle.com/n5bef5gepvx2fhaw

Using dates 2 weeks from now just as an example.  Pick a day/time of week 
that works, even if it doesn't work for this one week.

Let me know if there are any questions.

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




From ryman at ca.ibm.com  Thu Aug 25 16:32:02 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Thu, 25 Aug 2011 16:32:02 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
Message-ID: <OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>

Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 
http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 
literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 
There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 
suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 
it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 
convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 
than at the model level), so I believe that one couldn't use it to produce 
or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 
odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 
datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 
parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 
preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 
However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 
since it impairs interoperability.

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


Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 
thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 
use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 
of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 
a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 
in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 
XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 
note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 
syntax. And without that, I don't see a particular benefit in the stricter 
XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 
consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 
"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 
I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 
view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 
it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 
(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 
consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact

[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format



_______________________________________________
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

_______________________________________________
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






From ryman at ca.ibm.com  Thu Aug 25 16:47:05 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Thu, 25 Aug 2011 16:47:05 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>
	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.00713694@ca.ibm.com>
	<OF47D60F80.198D56B7-ON852578F5.00510D70-852578F5.005381E5@LocalDomain>
Message-ID: <OF8B61EA2A.1229F837-ON852578F7.00708173-852578F7.00722E69@ca.ibm.com>

Sam,

By "generic RDF/XML" I mean arbitrary, unconstrained RDF/XML. We started 
out trying to define a constrained RDF/XML for general use because we 
thought it would be easier to parse with standard XML technologies. 
However, we did not want to pay the price of defining this precisely, 
having a validator, etc. We soon found it was very hard to entice toolkits 
to generate RDF/XML that precisely fit our design. The closest we came was 
the so-called Abbreviated RDF/XML in Jena. There was no spec for that. I 
assume it's just supposed to be easier to read by humans. In the end we 
decided to abandon that approach and simply adopt the W3C RDF/XML spec.

However, as a legacy, that compact UI spec still used the constrained 
RDF/XML. However, we don't call it RDF. It's content type is 
application/xml. It just happens to also be valid RDF/XML but service 
providers are not allowed to use unconstrained RDF/XML. They have to 
generate precisely that format. We could even have written an XSD to 
describe the format. The goal was to make it easy to parse in browsers, 
i.e. not require full browser-based RDF parsers.

Yes, it would have made sense to use JSON for this purpose since browsers 
can more easily parse that. However, as a general rule, we want to 
minimize the number of formats a service provider has to support. This XML 
format is a MUST.

___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Samuel Padgett/Durham/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Randy 
Hudson/Raleigh/IBM at IBMUS
Date:
08/23/2011 11:12 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Hi, Arthur. Thanks for the answers. It clears some things up for me.

Arthur Ryman <ryman at ca.ibm.com> wrote on 08/22/2011 04:40:25 PM:

> I don't think problems using XPath are a valid reason to encode markup 
> since RDF/XML itselt is very difficult to process using XPath. At one 
> point we tried to define an OSLC-variant of RDF/XML that looked like 
> "normal" XML. However, we abandonned that and now require support for 
> generic RDF/XML.

To make sure I understand: By generic RDF/XML, you are talking about what 
the spec calls "constrained RDF/XML" in Appendix B, right? [1]

> The are many equivalent ways to represent a given set of triples in 
> RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
> XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
> RDF toolkit like Jena.

This makes sense, and I agree. But for me it also raises a few questions:

- Do we need a JSON Compact representation for consumers who don't use an 
RDF library? This is one of the few resources in OSLC that doesn't have a 
JSON representation, and it seems natural since so often the consumer here 
is a web client.

- Should we define a "constrained RDF/XML" representation if our 
recommendation is to use an RDF toolkit anyway? JSON might be a reasonable 
alternative for those who don't want RDF/XML.

Best Regards,
Sam

[1] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;up=#Guidelines_for_application_xml





From ryman at ca.ibm.com  Thu Aug 25 16:47:05 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Thu, 25 Aug 2011 16:47:05 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF9BE55011.703713F3-ON852578F5.004E4930-852578F5.00503AAD@LocalDomain>
References: <OFFA8DA82F.56EC8EF9-ON852578E5.005DB783-852578E5.005DF247@LocalDomain>
	<OF9753C7EA.88FADA58-ON852578E6.00551737-852578E6.00563C29@us.ibm.com>
	<OF0E2D2591.75954846-ON852578F4.0071129E-852578F4.00729A5D@ca.ibm.com>
	<OF9BE55011.703713F3-ON852578F5.004E4930-852578F5.00503AAD@LocalDomain>
Message-ID: <OF5FCD697E.449D13FA-ON852578F7.00719240-852578F7.00722E6C@ca.ibm.com>

Randy,

OSLC now supports W3C RDF/XML. This means all URIs are absolute although 
you  might compute them relative to the xml:base. But that is standard 
RDF/XML. Do you have an example where OSLC deviates from RDF/XML?

In RDF/XML the attribute rdf:parseType="Literal" means that the datatype 
is XMLLiteral.

I think I addressed your other comments in other responses.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel 
Padgett/Durham/IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS
Date:
08/23/2011 10:36 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


I don't think the value's datatype is the same as the parseType.  The data 
is [X]HTML, no matter what.  It is typically encoded, because that's the 
way you store a value in XML, and as long as you follow standard XML 
practice, using XPath to extract it has been pretty straightforward.  For 
better or worse, RDF/XML supports the use of parseType, but many OSLC 
consumers out there today are not going to handle documents that chose to 
use parseType.

Also, the value really needs to be a snippet of HTML, not XHTML.  Existing 
consumers are taking the value as if it were HTML and putting (after 
sanitizing) it directly in an existing HTML page.  I'm sure there would be 
problems consuming an XHTML snippet, for example, one that chose to assign 
the XHTML to a non-default namespace.

FWIW, there are other places where OSLC deviates from what RDF/XML allows. 
 e.g., requiring the use of absolute URIs.

-Randy





From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Adam Archer <agarcher at ca.ibm.com>, "oslc-core at open-services.net" 
<oslc-core at open-services.net>, oslc-core-bounces at open-services.net, Samuel 
Padgett/Durham/IBM at IBMUS, Steve K Speicher/Raleigh/IBM at IBMUS
Date:
08/22/2011 04:55 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

I think example [3] is wrong. If the datatype is plain text then you 
should not assume it contains encoded HTML. If you need to include markup 
then you should use XML Literal datatype, and use XHTML content. This is 
described in the core spec [4] which gives guidance for putting markup in 
dcterms:title and dcterms:description.

[4] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#Dublin_Core_Properties


Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube







From:
Randy Hudson <hudsonr at us.ibm.com>
To:
Samuel Padgett <spadgett at us.ibm.com>, Steve K Speicher 
<sspeiche at us.ibm.com>
Cc:
Adam Archer/Toronto/IBM at IBMCA, "oslc-core at open-services.net" 
<oslc-core at open-services.net>
Date:
08/08/2011 11:54 AM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Sam,

I agree that the spec needs to be more clear, but I don't agree with your
interpretation of the current spec.

If the spec says that a property's value is of type "string", then to
persist the string "<foo>" in XML+RDF, you must escape that string as
"&lt;foo&gt;" in the raw XML.  It's my understanding (and I could be 
wrong)
that this is true of any data type, including XML Literal.  So if the
title's value were "<b>foo</b>", persisting that value to XML+RDF would
require escaping characters like '<'.  Persisting that same value using
another format, like N3, maybe wouldn't require the same characters to be
escaped.

I have some suggested changes that I'll get to in a future email, but can
we first agree that the current spec's example does in fact agree with the
current spec?  I think it's important that we all start on the same page
before we write the next one :-)

-Randy


|------------>
| From:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Samuel Padgett/Durham/IBM                              |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net <oslc-core at open-services.net>            |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS, Adam Archer/Toronto/IBM at IBMCA 
                   |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/07/2011 01:06 PM                        |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |OSLC Compact representation, titles with markup         |
 
>--------------------------------------------------------------------------------------------------------------------------------------------------|




Small correction, that first example should be,

  <dcterms:title rdf:parseType="Literal">12345: <s>Null pointer exception
during startup</s></dcterms:title>

- Sam


__________________

I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

  <dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

  <dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

  <dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net









From hudsonr at us.ibm.com  Thu Aug 25 19:06:45 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Thu, 25 Aug 2011 19:06:45 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
Message-ID: <OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@us.ibm.com>

The following input is also equivalent:

<dcterms:title
rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
12345: &lt;s xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception
during startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value of
type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
      1.2.1 Inside the XML element add the value as a string with any
      required escaping

That would seem to suggest that the above form should be used.

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/25/2011 04:34 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for
http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the
literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.
There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test
suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,
it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a
convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other
than at the model level), so I believe that one couldn't use it to produce
or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so
odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF
datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The
parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of
preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.
However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged
since it impairs interoperability.

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



Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this
thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"
syntax. And without that, I don't see a particular benefit in the stricter
XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that
"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),
I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From joeross at us.ibm.com  Thu Aug 25 19:30:38 2011
From: joeross at us.ibm.com (Joe Ross)
Date: Thu, 25 Aug 2011 18:30:38 -0500
Subject: [oslc-core] domain URL for Service that supports creation/query of
 Service Provider resources
Message-ID: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>

In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 
We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability.

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec.

Thanks much,

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110825/e23c8a5e/attachment-0003.html>

From ryman at ca.ibm.com  Fri Aug 26 07:59:58 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 07:59:58 -0400
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
Message-ID: <OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>

Joe,

Your Service Provider registry service sounds interesting.

I am a little concerned about you using http://open-services.net/ns/core# 
as the domain since we haven't specified what that would mean. Here is the 
definition of  what a Domain is:

OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
Management, Requirements management or Automation. Each OSLC Domain will 
have its own OSLC specification that complies with this Core 
specification. 

I think we should have a spec that outlines the types of resources in the 
domain. You have selected just one type of  core resource.  Perhaps you 
should specify that and coin a URI for it?

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net
Date:
08/25/2011 10:49 PM
Subject:
[oslc-core] domain URL for Service that supports creation/query of Service 
Provider resources
Sent by:
oslc-core-bounces at open-services.net




In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 
We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability. 

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec. 

Thanks much, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From sspeiche at us.ibm.com  Fri Aug 26 09:08:21 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Fri, 26 Aug 2011 09:08:21 -0400
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
Message-ID: <OF45B1D423.FDCDF929-ON852578F8.0047766A-852578F8.00482D21@us.ibm.com>

Agree that this sounds like an interesting registry.  I also agree that 
what the spec says is quite restrictive in the sense of: 1) it doesn't 
allow for providers that don't fit any domain and 2) along these same 
lines, doesn't allow for pre-spec or proprietary explorations to introduce 
"private domains".

To accommodate these two cases, I see 3 different alternatives:
a. Just use the core namespace as Joe suggested
b. Invent a "private domain" namespace and use that
c. Create an OSLC WG, create a spec to support this, then use that 
namespace

Doing (a) requires us to modify the definition or intention in the spec, 
which I think is the most desirable.  Doing (b) has nice qualities but 
again would make use issue some changes to the spec.  Finally (c) is what 
we have today but requires a little overhead.

If there is the possibility of tweaking the spec, not making oslc:domain 
required on oslc:Service.  Though this has some breaking possibilities 
that we should avoid.  I believe the other options mentioned provide for 
the desired use case without impacting many, if any, clients.

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


> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Joe Ross/Austin/IBM at IBMUS, 
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 08/26/2011 08:00 AM
> Subject: Re: [oslc-core] domain URL for Service that supports 
creation/query
> of Service Provider resources
> Sent by: oslc-core-bounces at open-services.net
> 
> Joe,
> 
> Your Service Provider registry service sounds interesting.
> 
> I am a little concerned about you using 
http://open-services.net/ns/core# 
> as the domain since we haven't specified what that would mean. Here is 
the 
> definition of  what a Domain is:
> 
> OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
> Management, Requirements management or Automation. Each OSLC Domain will 

> have its own OSLC specification that complies with this Core 
> specification. 
> 
> I think we should have a spec that outlines the types of resources in 
the 
> domain. You have selected just one type of  core resource.  Perhaps you 
> should specify that and coin a URI for it?
> 
> Regards, 
> 
___________________________________________________________________________ 

> 
> Arthur Ryman 
> 
> DE, PPM & Reporting Chief Architect
> IBM Software, Rational 
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 
> 
> 
> 
> 
> 
> From:
> Joe Ross <joeross at us.ibm.com>
> To:
> oslc-core at open-services.net
> Date:
> 08/25/2011 10:49 PM
> Subject:
> [oslc-core] domain URL for Service that supports creation/query of 
Service 
> Provider resources
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> 
> In Tivoli, we are creating a Provider Registry that is itself 
implemented 
> as a Service Provider (a Service Provider for Service Provider 
resources). 
> We want to do this, so that we can support creation of Service Provider 
> records using a Creation Factory and querying for Service Providers 
using 
> a Query Capability. 
> 
> As part of defining the Service, we need to provide an oslc:domain with 
> namespace URI. Does it make sense for us to use the OSLC Core namespace 
> URI  (http://open-services.net/ns/core# ) for this? That seems logical 
> since all of the resources we are supporting in this Provider Registry 
> Service Provider are defined in the OSLC Core spec. 
> 
> Thanks much, 
> 
> ================================================
> Joe Ross/Austin/IBM, joeross at us.ibm.com
> Tivoli Autonomic Computing & Component Technologies
> 512-286-8311, T/L 
363-8311_______________________________________________
> 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




From sspeiche at us.ibm.com  Fri Aug 26 09:25:39 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Fri, 26 Aug 2011 09:25:39 -0400
Subject: [oslc-core] Minor problem in JSON Service Provider Resource
	example
In-Reply-To: <OF668F4399.44D2378F-ON852578F5.0068F15E-852578F5.0069B312@us.ibm.com>
References: <OF668F4399.44D2378F-ON852578F5.0068F15E-852578F5.0069B312@us.ibm.com>
Message-ID: <OFD093B94B.320C13F5-ON852578F8.00492FF1-852578F8.0049C29B@us.ibm.com>

Thanks Sam, made the fix.  After a quick sanity check, I also noticed that 
oslc:queryCapabilty has the same issue as oslc:service (should be an 
array).  Also the oslc:resourceShape (also renamed from oslc:shap) were 
objects and not arrays.  Think I fixed all the issues with it.  I also ran 
it through jslint.org to make sure it was valid still.

Let me know if I missed anything.

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

> From: Samuel Padgett/Durham/IBM at IBMUS
> To: "oslc-core at open-services.net" <oslc-core at open-services.net>, 
> Cc: Kevin Bauer/Raleigh/IBM at IBMUS
> Date: 08/23/2011 03:15 PM
> Subject: [oslc-core] Minor problem in JSON Service Provider Resource 
example
> Sent by: oslc-core-bounces at open-services.net
> 
> 
> Minor problem in the JSON Service Provider Resource example [1]: It 
looks
> like 'service' should be 'oslc:service', and the value should be a JSON
> array rather than a JSON object since it occurs 'one-or-many' [2].
> 
> - Best Regards, Sam
> 
> [1]
> http://open-services.net/bin/view/Main/OSLCCoreSpecJSONExamples?
> sortcol=table;up=#Service_Provider_Resource
> [2]
> http://open-services.net/bin/view/Main/OslcCoreSpecification?
> sortcol=table;up=#Service_Provider_Resources
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> 




From joeross at us.ibm.com  Fri Aug 26 09:50:24 2011
From: joeross at us.ibm.com (Joe Ross)
Date: Fri, 26 Aug 2011 08:50:24 -0500
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
Message-ID: <OFBB321C85.89A8EB60-ON862578F8.004B0E99-862578F8.004C0787@us.ibm.com>

Arthr,

We are actually  representing most (if not all) of the core resource types 
(Service, CreationFactory, QueryCapability, etc.) in the Provider Registry 
records.  Basically products register all of their capabilities and access 
points by OSLC core resource records in the Provider Registry. Most of the 
resources are in-line and part of the complete Service Provider record 
being registered. We will probably also need to register Resource Shapes 
and their properties for a complete understanding of provider 
capabilities.

Since these resource types are already defined in the Core specification, 
I would prefer not to have to redefine them all in a domain spec. 

Thanks,

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311



From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Joe Ross/Austin/IBM at IBMUS
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/26/2011 07:00 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources



Joe,

Your Service Provider registry service sounds interesting.

I am a little concerned about you using http://open-services.net/ns/core# 
as the domain since we haven't specified what that would mean. Here is the 

definition of  what a Domain is:

OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
Management, Requirements management or Automation. Each OSLC Domain will 
have its own OSLC specification that complies with this Core 
specification. 

I think we should have a spec that outlines the types of resources in the 
domain. You have selected just one type of  core resource.  Perhaps you 
should specify that and coin a URI for it?

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net
Date:
08/25/2011 10:49 PM
Subject:
[oslc-core] domain URL for Service that supports creation/query of Service 

Provider resources
Sent by:
oslc-core-bounces at open-services.net




In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 

We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability. 

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec. 

Thanks much, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
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/20110826/9db92abb/attachment-0003.html>

From ryman at ca.ibm.com  Fri Aug 26 10:04:31 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 10:04:31 -0400
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OFBB321C85.89A8EB60-ON862578F8.004B0E99-862578F8.004C0787@LocalDomain>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
	<OFBB321C85.89A8EB60-ON862578F8.004B0E99-862578F8.004C0787@LocalDomain>
Message-ID: <OF8A61BF8D.10B96647-ON852578F8.004C38F7-852578F8.004D52E2@ca.ibm.com>

Joe,

I didn't mean to imply you should redefine them. Just reference the core 
spec. Currently, the core spec isn't technically a domain. 

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross/Austin/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/26/2011 09:50 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources




Arthr, 

We are actually  representing most (if not all) of the core resource types 
(Service, CreationFactory, QueryCapability, etc.) in the Provider Registry 
records.  Basically products register all of their capabilities and access 
points by OSLC core resource records in the Provider Registry. Most of the 
resources are in-line and part of the complete Service Provider record 
being registered. We will probably also need to register Resource Shapes 
and their properties for a complete understanding of provider 
capabilities. 

Since these resource types are already defined in the Core specification, 
I would prefer not to have to redefine them all in a domain spec. 

Thanks, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311 


From: 
Arthur Ryman <ryman at ca.ibm.com> 
To: 
Joe Ross/Austin/IBM at IBMUS 
Cc: 
oslc-core at open-services.net, oslc-core-bounces at open-services.net 
Date: 
08/26/2011 07:00 AM 
Subject: 
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources




Joe,

Your Service Provider registry service sounds interesting.

I am a little concerned about you using http://open-services.net/ns/core# 
as the domain since we haven't specified what that would mean. Here is the 

definition of  what a Domain is:

OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
Management, Requirements management or Automation. Each OSLC Domain will 
have its own OSLC specification that complies with this Core 
specification. 

I think we should have a spec that outlines the types of resources in the 
domain. You have selected just one type of  core resource.  Perhaps you 
should specify that and coin a URI for it?

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Joe Ross <joeross at us.ibm.com>
To:
oslc-core at open-services.net
Date:
08/25/2011 10:49 PM
Subject:
[oslc-core] domain URL for Service that supports creation/query of Service 

Provider resources
Sent by:
oslc-core-bounces at open-services.net




In Tivoli, we are creating a Provider Registry that is itself implemented 
as a Service Provider (a Service Provider for Service Provider resources). 

We want to do this, so that we can support creation of Service Provider 
records using a Creation Factory and querying for Service Providers using 
a Query Capability. 

As part of defining the Service, we need to provide an oslc:domain with 
namespace URI. Does it make sense for us to use the OSLC Core namespace 
URI  (http://open-services.net/ns/core# ) for this? That seems logical 
since all of the resources we are supporting in this Provider Registry 
Service Provider are defined in the OSLC Core spec. 

Thanks much, 

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net










From joeross at us.ibm.com  Fri Aug 26 10:00:31 2011
From: joeross at us.ibm.com (Joe Ross)
Date: Fri, 26 Aug 2011 09:00:31 -0500
Subject: [oslc-core] domain URL for Service that supports creation/query
 of Service Provider resources
In-Reply-To: <OF45B1D423.FDCDF929-ON852578F8.0047766A-852578F8.00482C13@LocalDomain>
References: <OF26EF5679.A3B17B7C-ON862578F7.00806A06-862578F7.008126C7@us.ibm.com>
	<OF38B302E8.4575FF9B-ON852578F8.0040AB11-852578F8.0041EBB3@ca.ibm.com>
	<OF45B1D423.FDCDF929-ON852578F8.0047766A-852578F8.00482C13@LocalDomain>
Message-ID: <OFE49732DE.42E52B2F-ON862578F8.004BDA7D-862578F8.004CF4BD@us.ibm.com>

Steve,

We would  really prefer option (a). although I guess we could use option 
(b) informally, until necessary spec work is done. I don't think that we 
want to redefine all of the core resource types in another domain.

Even if oslc:domain is not required, there needs to be some property to 
allow clients to understand what kind of Service this is. We are planning 
to use domain to allow clients to select the Service they want to interact 
with.

Thanks,

Joe

================================================
Joe Ross/Austin/IBM, joeross at us.ibm.com
Tivoli Autonomic Computing & Component Technologies
512-286-8311, T/L 363-8311



From:
Steve K Speicher/Raleigh/IBM
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Joe Ross/Austin/IBM at IBMUS, oslc-core at open-services.net
Date:
08/26/2011 08:08 AM
Subject:
Re: [oslc-core] domain URL for Service that supports creation/query of 
Service Provider resources


Agree that this sounds like an interesting registry.  I also agree that 
what the spec says is quite restrictive in the sense of: 1) it doesn't 
allow for providers that don't fit any domain and 2) along these same 
lines, doesn't allow for pre-spec or proprietary explorations to introduce 
"private domains".

To accommodate these two cases, I see 3 different alternatives:
a. Just use the core namespace as Joe suggested
b. Invent a "private domain" namespace and use that
c. Create an OSLC WG, create a spec to support this, then use that 
namespace

Doing (a) requires us to modify the definition or intention in the spec, 
which I think is the most desirable.  Doing (b) has nice qualities but 
again would make use issue some changes to the spec.  Finally (c) is what 
we have today but requires a little overhead.

If there is the possibility of tweaking the spec, not making oslc:domain 
required on oslc:Service.  Though this has some breaking possibilities 
that we should avoid.  I believe the other options mentioned provide for 
the desired use case without impacting many, if any, clients.

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


> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Joe Ross/Austin/IBM at IBMUS, 
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 08/26/2011 08:00 AM
> Subject: Re: [oslc-core] domain URL for Service that supports 
creation/query
> of Service Provider resources
> Sent by: oslc-core-bounces at open-services.net
> 
> Joe,
> 
> Your Service Provider registry service sounds interesting.
> 
> I am a little concerned about you using 
http://open-services.net/ns/core# 
> as the domain since we haven't specified what that would mean. Here is 
the 
> definition of  what a Domain is:
> 
> OSLC Domain: an OSLC Domain is one ALM or PLM topic area such as Change 
> Management, Requirements management or Automation. Each OSLC Domain will 

> have its own OSLC specification that complies with this Core 
> specification. 
> 
> I think we should have a spec that outlines the types of resources in 
the 
> domain. You have selected just one type of  core resource.  Perhaps you 
> should specify that and coin a URI for it?
> 
> Regards, 
> 
___________________________________________________________________________ 

> 
> Arthur Ryman 
> 
> DE, PPM & Reporting Chief Architect
> IBM Software, Rational 
> Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 
> 
> 
> 
> 
> 
> From:
> Joe Ross <joeross at us.ibm.com>
> To:
> oslc-core at open-services.net
> Date:
> 08/25/2011 10:49 PM
> Subject:
> [oslc-core] domain URL for Service that supports creation/query of 
Service 
> Provider resources
> Sent by:
> oslc-core-bounces at open-services.net
> 
> 
> 
> 
> In Tivoli, we are creating a Provider Registry that is itself 
implemented 
> as a Service Provider (a Service Provider for Service Provider 
resources). 
> We want to do this, so that we can support creation of Service Provider 
> records using a Creation Factory and querying for Service Providers 
using 
> a Query Capability. 
> 
> As part of defining the Service, we need to provide an oslc:domain with 
> namespace URI. Does it make sense for us to use the OSLC Core namespace 
> URI  (http://open-services.net/ns/core# ) for this? That seems logical 
> since all of the resources we are supporting in this Provider Registry 
> Service Provider are defined in the OSLC Core spec. 
> 
> Thanks much, 
> 
> ================================================
> Joe Ross/Austin/IBM, joeross at us.ibm.com
> Tivoli Autonomic Computing & Component Technologies
> 512-286-8311, T/L 
363-8311_______________________________________________
> 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/20110826/7fabc50c/attachment-0003.html>

From ryman at ca.ibm.com  Fri Aug 26 14:22:28 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 14:22:28 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
Message-ID: <OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@ca.ibm.com>

Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 

it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 

convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 

than at the model level), so I believe that one couldn't use it to produce 

or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 

odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 

datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 

parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 

preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 

However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 

since it impairs interoperability.

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



Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 

use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 

of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 

a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 

in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 

XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 

note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 

syntax. And without that, I don't see a particular benefit in the stricter 

XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 

consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 

"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 

I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 

view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 

it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 

(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 

consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From hudsonr at us.ibm.com  Fri Aug 26 14:48:56 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Fri, 26 Aug 2011 14:48:56 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
Message-ID: <OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@us.ibm.com>

Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get
jena to write out the property this way by setting an option on the writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the value's
type in its serialized form in cases where only one datatype is allowed.
It looks like bits of the "schema" get repeated over and over.

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman/Toronto/IBM at IBMCA                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, oslc-core-bounces at open-services.net                                             |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/26/2011 02:22 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________
                                                                              
 Arthur Ryman                                        (Embedded image moved to 
                                                          file: pic19425.gif) 
                                                                              
 DE, PPM & Reporting Chief Architect                                          
                                                                              
 IBM Software, Rational                                                       
                                                                              
 Toronto Lab | +1-905-413-3077 (office) |                                     
 +1-416-939-5063 (mobile)                                                     
                                                                              





|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Randy Hudson/Raleigh/IBM at IBMUS                                                                                                                    |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, oslc-core-bounces at open-services.net                                             |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/25/2011 07:06 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value of
type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
      1.2.1 Inside the XML element add the value as a string with any
      required escaping

That would seem to suggest that the above form should be used.

-Randy



|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/25/2011 04:34 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for
http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the
literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.
There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test
suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,
it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a
convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other
than at the model level), so I believe that one couldn't use it to produce
or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so
odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties
- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF
datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The
parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose
the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of
preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.
However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged
since it impairs interoperability.

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



Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this
thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the
use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use
of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use
a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral
in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other
XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And
note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"
syntax. And without that, I don't see a particular benefit in the stricter
XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a
consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that
"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),
I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of
view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation
it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons
(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all
consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________


Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic19425.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/b0ca3e53/attachment.gif>

From davidms at ca.ibm.com  Fri Aug 26 15:21:02 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 15:21:02 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
Message-ID: <OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>


Arthur,

I believe you're mistaken. I think that parseType="Literal" is just
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make
it easy to write literals of this kind"). Either way you write it, you end
up with the same statement. Two statements with the same subject, the same
predicate and a typed literal with the same type
(<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with
some sort of privileged XMLLiteral representation that couldn't written out
using any other RDF notation.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com



                                                                                                             
  From:       Arthur Ryman/Toronto/IBM                                                                       
                                                                                                             
  To:         Randy Hudson/Raleigh/IBM at IBMUS                                                                 
                                                                                                             
  Cc:         Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,                              
              oslc-core-bounces at open-services.net                                                            
                                                                                                             
  Date:       08/26/2011 02:22 PM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             





Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,

it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a

convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other

than at the model level), so I believe that one couldn't use it to produce

or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so

odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF

datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The

parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of

preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.

However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged

since it impairs interoperability.

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




Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the

use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use

of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use

a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral

in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other

XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And

note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"

syntax. And without that, I don't see a particular benefit in the stricter

XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a

consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that

"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),

I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of

view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation

it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons

(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all

consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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/20110826/edb5c99c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/edb5c99c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/edb5c99c/attachment-0001.gif>

From ryman at ca.ibm.com  Fri Aug 26 15:58:50 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 15:58:50 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
Message-ID: <OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006DC2EF@ca.ibm.com>

Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you 
include element content. If you use rdf:datatype then only character 
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal" 
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince 
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 03:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just 
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make 
it easy to write literals of this kind"). Either way you write it, you end 
up with the same statement. Two statements with the same subject, the same 
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same 
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with 
some sort of privileged XMLLiteral representation that couldn't written 
out using any other RDF notation.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the 
content a string that looks like XHTML, i.e. the


From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 


http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 


literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 


There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 


suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 


it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 



Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 


convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 


than at the model level), so I believe that one couldn't use it to produce 


or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 


odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 


- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 


datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 


parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 


the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 


preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 


However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 


since it impairs interoperability.

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




Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 


thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 


use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 


of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 


a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 


in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 


XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 


note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 


syntax. And without that, I don't see a particular benefit in the stricter 


XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 


consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 


"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 


I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 


view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 


it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 


(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 


consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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






From ryman at ca.ibm.com  Fri Aug 26 16:13:52 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:13:52 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
	<OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
Message-ID: <OF8CEBFEC5.987439B3-ON852578F8.006E00F0-852578F8.006F2349@ca.ibm.com>

Randy,

I validated the RDF at the W3C Validator. I've also tried it out via 
Fuseki which uses Jena.

As I said, you can have a datatype of XMLLiteral that happens to include 
just a string which may include escaped characters, e.g. " 1 &lt; 2".  For 
it to be XHTML, it should have elements in the XHTML namespace.

 I just checked the Jena wiki [1]. Note the example:

More about Literals and Datatypes
RDF literals are not just simple strings. Literals may have a language tag 
to indicate the language of the literal. The literal "chat" with an 
English language tag is considered different to the literal "chat" with a 
French language tag. This rather strange behaviour is an artefact of the 
original RDF/XML syntax.
Further there are really two sorts of Literals. In one, the string 
component is just that, an ordinary string. In the other the string 
component is expected to be a well balanced fragment of XML. When an RDF 
Model is written as RDF/XML a special construction using a 
parseType='Literal' attribute is used to represent it.
In Jena, these attributes of a literal may be set when the literal is 
constructed, e.g. in tutorial 11:
// create the resource
Resource r = model.createResource();

// add the property
r.addProperty(RDFS.label, model.createLiteral("chat", "en"))
 .addProperty(RDFS.label, model.createLiteral("chat", "fr"))
 .addProperty(RDFS.label, model.createLiteral("<em>chat</em>", true));

// write out the Model
model.write(system.out);
produces
<rdf:RDF
  xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
  xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#'
 >
  <rdf:Description rdf:nodeID="A0">
    <rdfs:label xml:lang='en'>chat</rdfs:label>
    <rdfs:label xml:lang='fr'>chat</rdfs:label>
    <rdfs:label rdf:parseType='Literal'><em>chat</em></rdfs:label>
  </rdf:Description>
</rdf:RDF>


[1] 
http://jena.sourceforge.net/tutorial/RDF_API/#ch-More%20about%20Literals%20and%20Datatypes

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get 
jena to write out the property this way by setting an option on the 
writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when 
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the 
value's type in its serialized form in cases where only one datatype is 
allowed.  It looks like bits of the "schema" get repeated over and over.

-Randy




From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 






From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 

it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 

convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 

than at the model level), so I believe that one couldn't use it to produce 

or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 

odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 

datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 

parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 

preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 

However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 

since it impairs interoperability.

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



Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 

use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 

of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 

a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 

in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 

XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 

note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 

syntax. And without that, I don't see a particular benefit in the stricter 

XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 

consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 

"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 

I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 

view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 

it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 

(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 

consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net







From ryman at ca.ibm.com  Fri Aug 26 16:28:54 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:28:54 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
	<OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
Message-ID: <OF6FE7077F.DBDB00DB-ON852578F8.006F1789-852578F8.007083BA@ca.ibm.com>

Randy,

For your second question/comment: 

[Off topic]  I'm not sure I really see the benefit to including the 
value's type in its serialized form in cases where only one datatype is 
allowed.  It looks like bits of the "schema" get repeated over and over.

The reason is that there is no "schema" in the usual OO or database sense. 
An RDF property can have any value and be repeated multiple times with 
different values. In the case of OSLC, we try to say what to expect via 
ResourceShapes, and we could "cast" plain literals to the correct data 
value. However, we expect our RDF to be consumed by other applications and 
so we need to include the datatypes to avoid ambiguity, e.g. is "true" a 
boolean or a string?

I do agree that RDF looks very verbose with all the datatypes.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get 
jena to write out the property this way by setting an option on the 
writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when 
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the 
value's type in its serialized form in cases where only one datatype is 
allowed.  It looks like bits of the "schema" get repeated over and over.

-Randy




From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 






From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>
 
3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 

it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 

convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 

than at the model level), so I believe that one couldn't use it to produce 

or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 

odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 

datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 

parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 

preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 

However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 

since it impairs interoperability.

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



Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 

use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 

of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 

a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 

in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 

XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 

note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 

syntax. And without that, I don't see a particular benefit in the stricter 

XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 

consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 

"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 

I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 

view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 

it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 

(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 

consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 


Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact


[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format




_______________________________________________
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

_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net







From davidms at ca.ibm.com  Fri Aug 26 16:37:55 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 16:37:55 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
Message-ID: <OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@ca.ibm.com>


Hi again Arthur,

Lots of good points to address, so my responses are inline (also note that
I wrote my previous, short reply to your later message in the middle of
writing this longer one, so there may be a bit of overlap).

[Disclaimer: I realize I'm talking a lot about Jena in this message. That's
because it's what I know. If there are other RDF toolkits in use, their
behaviour is certainly relevant, too, and it would be good to hear from
people with knowledge of them.]

Arthur Ryman/Toronto/IBM wrote on 08/25/2011 04:27:40 PM:
>
> 1. XML Namespaces.
>
> The spec doesn't say "for XHTML, you need to insert an xmlns attribute
for
> http://www.w3.org/1999/xhtml" because that is part of the XHTML
> standard, i.e. it's not XHTML unless the elements are in the XHTML
namespace.

I agree that XHTML does mean using the XHTML namespace, but I also believe
it would have been helpful to underline that fact in the OSLC Core spec.
Also, I still can't find a single example in the spec that actually shows
markup in the value of an XMLLiteral-typed literal, which also would have
been helpful. I notice that RTC doesn't use a namespace, so I suppose it
wasn't obvious to them.

> 2. Jena
>
> I loaded the sample RDF/XML  into Fuseki which uses Jena and it
> produced the correct result. I assume the Jena API lets you get an
> XML DOM from the literal value.

Thanks for this! I didn't know this, and it's reassuring. I was able to
replicate this behaviour with pure Jena, simply by loading an RDF/XML
resource containing your input and printing the type and lexical form of
the literal:

Datatype: http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
Lexical form:  12345: <s xmlns="http://www.w3.org/1999/xhtml">Null pointer
exception during startup</s>

Unfortunately, though, your assumption is not correct: Jena provides no
access to underlying DOM. It appears that during parsing it computes the
exclusive canonical form of the XML subset, as the RDF specs prescribe, and
simply records that as the literal's lexical value. But, Jena's built-in
XMLLiteral type support just uses java.lang.String as its value type. I was
surprised when I first discovered that, too, but you can see for yourself
in XMLLiteralType.parse().

> 3.  XHTML versus HTML
>
> The primary reason is that RDF supports XHTML via the XMLLiteral
> datatype. There is no parsing support for HTML built into RDF.

RDF doesn't require parsing support to use other datatypes, at least not in
the abstract sense. Abstractly, a typed literal is just a datatype
(identified by a URI) and a lexical form. Of course, it's very helpful in
an implementation if you can automatically convert that to a more useful
typed value (i.e. an Integer, Boolean, etc.), but that's purely a toolkit
concern. Jena will support any datatype via its BaseDatatype.TypedValue
wrapper type, but it's pluggable, so you can add specific parsing support
for any type you wish.

> Another strong reason is that the syntax of HTML is very irregular
> and hard to parse correctly - that is one of the reasons XML was
> invented. This is very important from a security viewpoint. To guard
> against script injection attacks, you really should parse the input
> and remove any <script> elements or Javascript attributes. Doing
> that correctly for HTML requires a full HTML parser. On the other
> hand, the XHTML is given to you as a DOM which you can easily
> traverse or process using XSLT or XPATH.

But as you said, HTML Tidy can be used to parse HTML. You could even plug
it in to Jena to do the parsing automatically for a defined datatype, which
would be more convenient than the built in XMLLiteral support. Also, I
really think that whether or not you need to parse and cleanse depends upon
what you're doing with the data. It may not be necessary for an OSLC
adapter that's merely passing along data from a trusted source, since it's
incumbent upon a security-conscious client to do that, itself.

> 4. Datatypes
>
> The specs do specify the datatypes for some properties. Look at the
> Value-Type column of the tables, e.g. [1]. You need to include the
> datatype explicitly for ints, dates, XML. etc. You specify that
> using rdf:datatype in RDF/XML, or using ^^ in Turtle.

Sorry if I wasn't clear. What I meant was that specs don't appear to say
whether consumers and producers should use/expect typed literals or plain
literals. I do see that the tables prescribe datatypes for the various
literal-typed properties, but it doesn't say anywhere whether that means
that typed literals should actually be used to specify those types, or that
plain literals should be used (since those prescribed types are already
presumed to be known).

> 5. Inventing new Datatypes
>
> The RDF spec defines the XSD datatypes and the XMLLiteral datatype.
> RDF parsers know how to parse those. If someone introduces a new
> datatype URI, it could break parsers since they won't know how to
> parse the contents. There is no standard way to define new datatypes.
>
> Try it with the RDF Validation service [2]

I had no problem parsing the following RDF/XML document (in which I've used
my own HTML type) with the service:

<rdf:RDF
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:oslc_cm="http://open-services.net/ns/cm#" >
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title
rdf:datatype="http://open-services.net/ns/core/types#HTML">12345:
&lt;s&gt;Null pointer exception during startup&lt;/s&gt;</dcterms:title>
    <rdf:type rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
  </rdf:Description>
</rdf:RDF>


Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/af37fbae/attachment-0003.html>

From hudsonr at us.ibm.com  Fri Aug 26 16:48:13 2011
From: hudsonr at us.ibm.com (Randy Hudson)
Date: Fri, 26 Aug 2011 16:48:13 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006DC2EF@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006DC2EF@ca.ibm.com>
Message-ID: <OF2E1EAFE2.B98E1BAD-ON852578F8.0071D7CE-852578F8.0072473A@us.ibm.com>

Either that validator is completely broken, or RDF/XML doesn't support
strings containing the character "<".

    <dc:title">World Wide Web &lt; Consortium</dc:title>

Jena will both produce and consume the alternate syntax I provided before.

-Randy


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Arthur Ryman <ryman at ca.ibm.com>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Dave Steinberg <davidms at ca.ibm.com>                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/26/2011 03:59 PM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [oslc-core] OSLC Compact representation, titles with markup                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |oslc-core-bounces at open-services.net                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|





Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you
include element content. If you use rdf:datatype then only character
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal"
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 03:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make
it easy to write literals of this kind"). Either way you write it, you end
up with the same statement. Two statements with the same subject, the same
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with
some sort of privileged XMLLiteral representation that couldn't written
out using any other RDF notation.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the
content a string that looks like XHTML, i.e. the


From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for


http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the


literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.


There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test


suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,


it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________




Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a


convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other


than at the model level), so I believe that one couldn't use it to produce


or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so


odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties


- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF


datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The


parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose


the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of


preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.


However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged


since it impairs interoperability.

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





Regards,
___________________________________________________________________________




Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this


thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the


use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use


of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use


a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral


in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other


XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And


note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"


syntax. And without that, I don't see a particular benefit in the stricter


XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a


consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that


"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),


I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of


view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation


it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons


(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all


consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________




Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact




[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format






_______________________________________________
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

_______________________________________________
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




_______________________________________________
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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





From davidms at ca.ibm.com  Fri Aug 26 16:54:10 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 16:54:10 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
	<OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@LocalDomain>
Message-ID: <OF7C87C9F9.066C4358-ON852578F8.00728620-852578F8.0072D2F4@ca.ibm.com>


Dave Steinberg/Toronto/IBM wrote on 08/26/2011 04:37:55 PM:

> I had no problem parsing the following RDF/XML document (in which
> I've used my own HTML type) with the service:

Oops. I see that the validator is reporting a value with the &lt;s and
&gt;s intact. I believe that must be an error; it's not bothering to
interpret the XML entities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/350dc129/attachment-0003.html>

From ryman at ca.ibm.com  Fri Aug 26 16:58:10 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:58:10 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF7C87C9F9.066C4358-ON852578F8.00728620-852578F8.0072D2F4@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>	<OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@LocalDomain>
	<OF7C87C9F9.066C4358-ON852578F8.00728620-852578F8.0072D2F4@ca.ibm.com>
Message-ID: <OF46D3DE46.982C94EE-ON852578F8.007323A0-852578F8.007331C1@ca.ibm.com>

Dave,

I believe it's just escaping them for output.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 04:54 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave Steinberg/Toronto/IBM wrote on 08/26/2011 04:37:55 PM:

> I had no problem parsing the following RDF/XML document (in which 
> I've used my own HTML type) with the service:

Oops. I see that the validator is reporting a value with the &lt;s and 
&gt;s intact. I believe that must be an error; it's not bothering to 
interpret the XML entities._______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Fri Aug 26 16:58:10 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Fri, 26 Aug 2011 16:58:10 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.00706571@LocalDomain>
	<OF91AD0277.6CEDAD24-ON852578F8.0062182C-852578F8.00715611@ca.ibm.com>
Message-ID: <OFA3FECFEF.ECCAA761-ON852578F8.00724F0D-852578F8.007331BE@ca.ibm.com>

Dave,

It's good to know that the W3C RDF Validator accepted your private 
datatype. However, I haven't seen new datatypes being introduced by other 
vocabularies. If we do that it might reduce interoperablility.

Too bad Jena doesn't give you a DOM. Reparsing doesn't seem too 
inconvenient.

Omitting the datatypes because "we" know what they should be would reduce 
interoperability. We assume other applications will use our RDF resources, 
so we should make them explicit.

I agree the spec could be clearer. I believe Steve is improving it.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 04:39 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi again Arthur,

Lots of good points to address, so my responses are inline (also note that 
I wrote my previous, short reply to your later message in the middle of 
writing this longer one, so there may be a bit of overlap).

[Disclaimer: I realize I'm talking a lot about Jena in this message. 
That's because it's what I know. If there are other RDF toolkits in use, 
their behaviour is certainly relevant, too, and it would be good to hear 
from people with knowledge of them.]

Arthur Ryman/Toronto/IBM wrote on 08/25/2011 04:27:40 PM:
> 
> 1. XML Namespaces. 
> 
> The spec doesn't say "for XHTML, you need to insert an xmlns attribute 
for 
> http://www.w3.org/1999/xhtml" because that is part of the XHTML 
> standard, i.e. it's not XHTML unless the elements are in the XHTML 
namespace. 

I agree that XHTML does mean using the XHTML namespace, but I also believe 
it would have been helpful to underline that fact in the OSLC Core spec. 
Also, I still can't find a single example in the spec that actually shows 
markup in the value of an XMLLiteral-typed literal, which also would have 
been helpful. I notice that RTC doesn't use a namespace, so I suppose it 
wasn't obvious to them.

> 2. Jena
> 
> I loaded the sample RDF/XML  into Fuseki which uses Jena and it 
> produced the correct result. I assume the Jena API lets you get an 
> XML DOM from the literal value.

Thanks for this! I didn't know this, and it's reassuring. I was able to 
replicate this behaviour with pure Jena, simply by loading an RDF/XML 
resource containing your input and printing the type and lexical form of 
the literal:

Datatype: http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
Lexical form:  12345: <s xmlns="http://www.w3.org/1999/xhtml">Null pointer 
exception during startup</s>

Unfortunately, though, your assumption is not correct: Jena provides no 
access to underlying DOM. It appears that during parsing it computes the 
exclusive canonical form of the XML subset, as the RDF specs prescribe, 
and simply records that as the literal's lexical value. But, Jena's 
built-in XMLLiteral type support just uses java.lang.String as its value 
type. I was surprised when I first discovered that, too, but you can see 
for yourself in XMLLiteralType.parse().

> 3.  XHTML versus HTML
> 
> The primary reason is that RDF supports XHTML via the XMLLiteral 
> datatype. There is no parsing support for HTML built into RDF.

RDF doesn't require parsing support to use other datatypes, at least not 
in the abstract sense. Abstractly, a typed literal is just a datatype 
(identified by a URI) and a lexical form. Of course, it's very helpful in 
an implementation if you can automatically convert that to a more useful 
typed value (i.e. an Integer, Boolean, etc.), but that's purely a toolkit 
concern. Jena will support any datatype via its BaseDatatype.TypedValue 
wrapper type, but it's pluggable, so you can add specific parsing support 
for any type you wish.

> Another strong reason is that the syntax of HTML is very irregular 
> and hard to parse correctly - that is one of the reasons XML was 
> invented. This is very important from a security viewpoint. To guard
> against script injection attacks, you really should parse the input 
> and remove any <script> elements or Javascript attributes. Doing 
> that correctly for HTML requires a full HTML parser. On the other 
> hand, the XHTML is given to you as a DOM which you can easily 
> traverse or process using XSLT or XPATH.

But as you said, HTML Tidy can be used to parse HTML. You could even plug 
it in to Jena to do the parsing automatically for a defined datatype, 
which would be more convenient than the built in XMLLiteral support. Also, 
I really think that whether or not you need to parse and cleanse depends 
upon what you're doing with the data. It may not be necessary for an OSLC 
adapter that's merely passing along data from a trusted source, since it's 
incumbent upon a security-conscious client to do that, itself.

> 4. Datatypes
> 
> The specs do specify the datatypes for some properties. Look at the 
> Value-Type column of the tables, e.g. [1]. You need to include the 
> datatype explicitly for ints, dates, XML. etc. You specify that 
> using rdf:datatype in RDF/XML, or using ^^ in Turtle. 

Sorry if I wasn't clear. What I meant was that specs don't appear to say 
whether consumers and producers should use/expect typed literals or plain 
literals. I do see that the tables prescribe datatypes for the various 
literal-typed properties, but it doesn't say anywhere whether that means 
that typed literals should actually be used to specify those types, or 
that plain literals should be used (since those prescribed types are 
already presumed to be known).

> 5. Inventing new Datatypes
> 
> The RDF spec defines the XSD datatypes and the XMLLiteral datatype. 
> RDF parsers know how to parse those. If someone introduces a new 
> datatype URI, it could break parsers since they won't know how to 
> parse the contents. There is no standard way to define new datatypes. 
> 
> Try it with the RDF Validation service [2]

I had no problem parsing the following RDF/XML document (in which I've 
used my own HTML type) with the service:

<rdf:RDF
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:oslc_cm="http://open-services.net/ns/cm#" > 
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title rdf:datatype="
http://open-services.net/ns/core/types#HTML">12345: &lt;s&gt;Null pointer 
exception during startup&lt;/s&gt;</dcterms:title>
    <rdf:type rdf:resource="http://open-services.net/ns/cm#ChangeRequest
"/>
  </rdf:Description>
</rdf:RDF>


Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From davidms at ca.ibm.com  Fri Aug 26 17:31:11 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 17:31:11 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
Message-ID: <OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>


Hi Arthur,

Sorry, but I just don't agree. The two links you gave are both to the
RDF/XML spec, and they describe a special syntax for XMLLiteral-typed
literals and a general syntax for typed literals. They do not state that
the general syntax cannot be used for the case of XMLLiteral, and they
don't say anything that contradicts my understanding of the RDF abstract
data model.

Indeed, if you follow the "XML literals" link in Section 2.8, the RDF
Concepts spec defines XMLLiteral, like any other datatype, with a lexical
space, a value space and a mapping between the two. So, given any XML
value, what is to prevent you from using that mapping to compute a
corresponding lexical form, combining it with the datatype URI, and using
the ordinary literal notation (in any RDF concrete syntax)?

I just tried entering the following two RDF/XML documents into the
validation service:

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title rdf:parseType="Literal"
xmlns="http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception
during startup</s></dcterms:title>
  </rdf:Description>
</rdf:RDF>

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title
rdf:datatype="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">
12345: &lt;s xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception
during startup&lt;/s&gt;</dcterms:title>
  </rdf:Description>
</rdf:RDF>

It yielded exactly the same result in both cases:



I can also confirm Steve's claim that Jena can be configured to write out
exactly the same triples using either syntax.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                                                                
  From:       Arthur Ryman/Toronto/IBM                                                                                                          
                                                                                                                                                
  To:         Dave Steinberg/Toronto/IBM at IBMCA                                                                                                  
                                                                                                                                                
  Cc:         oslc-core at open-services.net, oslc-core-bounces at open-services.net                                                                  
                                                                                                                                                
  Date:       08/26/2011 03:58 PM                                                                                                               
                                                                                                                                                
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                                                   
                                                                                                                                                




Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you
include element content. If you use rdf:datatype then only character
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal"
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________
                                                                              
 Arthur Ryman                                                                 
                                                                              
 DE, PPM & Reporting Chief Architect                                          
                                                                              
 IBM Software, Rational                                                       
                                                                              
 Toronto Lab | +1-905-413-3077 (office) |                                     
 +1-416-939-5063 (mobile)                                                     
                                                                              





                                                                                                                                                
  From:       Dave Steinberg/Toronto/IBM at IBMCA                                                                                                  
                                                                                                                                                
  To:         oslc-core at open-services.net                                                                                                       
                                                                                                                                                
  Date:       08/26/2011 03:22 PM                                                                                                               
                                                                                                                                                
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                                                   
                                                                                                                                                
  Sent by:    oslc-core-bounces at open-services.net                                                                                               
                                                                                                                                                





Arthur,

I believe you're mistaken. I think that parseType="Literal" is just
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make
it easy to write literals of this kind"). Either way you write it, you end
up with the same statement. Two statements with the same subject, the same
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with
some sort of privileged XMLLiteral representation that couldn't written out
using any other RDF notation.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Inactive hide details for Arthur Ryman---08/26/2011 02:22:29 PM---Randy,
Your example makes the content a string that looks likArthur
Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the content a
string that looks like XHTML, i.e. the
                                                                           
                                                                           
 From:      Arthur Ryman/Toronto/IBM                                       
                                                                           
                                                                           
 To:        Randy Hudson/Raleigh/IBM at IBMUS                                 
                                                                           
                                                                           
 Cc:        Dave Steinberg <davidms at ca.ibm.com>,                           
            oslc-core at open-services.net,                                   
            oslc-core-bounces at open-services.net                            
                                                                           
                                                                           
 Date:      08/26/2011 02:22 PM                                            
                                                                           
                                                                           
 Subject:   Re: [oslc-core] OSLC Compact representation, titles with       
            markup                                                         
                                                                           





Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,

it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a

convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other

than at the model level), so I believe that one couldn't use it to produce

or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so

odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF

datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The

parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of

preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.

However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged

since it impairs interoperability.

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




Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the

use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use

of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use

a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral

in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other

XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And

note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"

syntax. And without that, I don't see a particular benefit in the stricter

XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a

consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that

"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),

I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of

view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation

it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons

(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all

consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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/20110826/ff138409/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12375707.gif
Type: image/gif
Size: 9285 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12992179.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/ff138409/attachment-0003.gif>

From davidms at ca.ibm.com  Fri Aug 26 17:35:00 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 17:35:00 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
Message-ID: <OFD7B386AA.44702968-ON852578F8.007682D9-852578F8.0076901F@ca.ibm.com>

> I can also confirm Steve's claim that Jena can be configured to
> write out exactly the same triples using either syntax.

Apologies: Randy's claim.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/945dd6af/attachment-0003.html>

From davidms at ca.ibm.com  Fri Aug 26 19:50:29 2011
From: davidms at ca.ibm.com (Dave Steinberg)
Date: Fri, 26 Aug 2011 19:50:29 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF6FE7077F.DBDB00DB-ON852578F8.006F1789-852578F8.007083BA@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFF1566BE0.1AE77FA5-ON852578F4.00708074-852578F4.0070F5A0@LocalDomain>
	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0063C4C8@LocalDomain>
	<OF0FAB2C7D.EDE9A417-ON852578F8.00665B0F-852578F8.00675B84@LocalDomain>
	<OF6FE7077F.DBDB00DB-ON852578F8.006F1789-852578F8.007083BA@LocalDomain>
Message-ID: <OFB3D589A2.890AE53F-ON852578F8.0081463F-852578F8.0082F769@ca.ibm.com>


Hi all,

I totally agree with Arthur on this. I think typed literals are a valuable
feature of RDF, and well worth using. As Arthur says, they allow a consumer
to make more sense of a literal value without already having a schema or
resource shape. Moreover, they allow you to use the same properties with
different types in a single resource. This is actually directly applicable
to the issue at hand with XHTML in compact rendering. Instead of defining
additional properties likes oslc:htmlEncodedTitle, we could define an HTML
type and use it as follows:

<rdf:RDF
    xmlns:oslc_types="http://open-services.net/ns/core/types#"
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
  <rdf:Description rdf:about="http://example.com/bugs/2314">
    <dcterms:title
rdf:datatype="http://open-services.net/ns/core/types#HTML">12345:
&lt;s&gt;Null pointer exception during startup&lt;/s&gt;</dcterms:title>
    <dcterms:title rdf:parseType="Literal">12345: <s
xmlns="http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>
  </rdf:Description>
</rdf:RDF>

This seems the more natural RDF approach to me, and you only need to define
one new type, which you could use with any number of properties.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com



                                                                                                             
  From:       Arthur Ryman/Toronto/IBM                                                                       
                                                                                                             
  To:         Randy Hudson/Raleigh/IBM at IBMUS                                                                 
                                                                                                             
  Cc:         Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,                              
              oslc-core-bounces at open-services.net                                                            
                                                                                                             
  Date:       08/26/2011 04:28 PM                                                                            
                                                                                                             
  Subject:    Re: [oslc-core] OSLC Compact representation, titles with markup                                
                                                                                                             





Randy,

For your second question/comment:

[Off topic]  I'm not sure I really see the benefit to including the
value's type in its serialized form in cases where only one datatype is
allowed.  It looks like bits of the "schema" get repeated over and over.

The reason is that there is no "schema" in the usual OO or database sense.
An RDF property can have any value and be repeated multiple times with
different values. In the case of OSLC, we try to say what to expect via
ResourceShapes, and we could "cast" plain literals to the correct data
value. However, we expect our RDF to be consumed by other applications and
so we need to include the datatypes to avoid ambiguity, e.g. is "true" a
boolean or a string?

I do agree that RDF looks very verbose with all the datatypes.

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Arthur,

Did you try it out?  I tested it, although in reverse.  I was able to get
jena to write out the property this way by setting an option on the
writer:

writer.setProperty("blockRules", new Resource[]{RDFSyntax.
parseTypeLiteralPropertyElt});

Why would someone reading that property think the value is a string when
the datatype says otherwise?

[Off topic]  I'm not sure I really see the benefit to including the
value's type in its serialized form in cases where only one datatype is
allowed.  It looks like bits of the "schema" get repeated over and over.

-Randy




From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Randy Hudson/Raleigh/IBM at IBMUS
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/26/2011 02:22 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


Randy,

Your example makes the content a string that looks like XHTML, i.e. the
content contains no XHTML elements since all the markup characters are
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to
include characters that might get misinterpreted as XML markup. For
example, consider a math statement like "1 < 2". When you put that in an
XML element, you need to encode it as "1 &lt; 2"

Regards,
___________________________________________________________________________


Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)






From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type
1.2.1 Inside the XML element add the value as a string with any required
escaping

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces.

RDF/XML is well-formed XML so it must support namespaces correctly. For
triples whose datatype is XML Literal, the value of this literal is a
well-formed XML fragment, and therefore the namespaces should be present
in the content. If there is an enclosing <span> element, then the
namespace should be there. Otherwise, each element in the content should
have the namespace.

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for

http://www.w3.org/1999/xhtml" because that is part of the XHTML standard,
i.e. it's not XHTML unless the elements are in the XHTML namespace.

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced
the correct result. I assume the Jena API lets you get an XML DOM from the

literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype.

There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and
hard to parse correctly - that is one of the reasons XML was invented.
This is very important from a security viewpoint. To guard against script
injection attacks, you really should parse the input and remove any
<script> elements or Javascript attributes. Doing that correctly for HTML
requires a full HTML parser. On the other hand, the XHTML is given to you
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the
Value-Type column of the tables, e.g. [1]. You need to include the
datatype explicitly for ints, dates, XML. etc. You specify that using
rdf:datatype in RDF/XML, or using ^^ in Turtle.

I don't know what the state of adoption is. We really should get some test

suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF
parsers know how to parse those. If someone introduces a new datatype URI,

it could break parsers since they won't know how to parse the contents.
There is no standard way to define new datatypes.

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards,
___________________________________________________________________________



Arthur Ryman

DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a

convenience, but only if tools supported that. As far as I could find,
Jena provides no fine-grained access to namespace declarations (i.e. other

than at the model level), so I believe that one couldn't use it to produce

or consume the fragment that you suggested. Moreover, the other RDF
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a
pretty significant one, and not one that's reflected in the specs, since
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML.
That was very helpful for me. But I must admit, I'm still left wondering
what makes XHTML superior to HTML for interchanging formatted text,
especially in light of the compact representation example and my own
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance
in the OSLC specs specifically about plain vs. typed literals. It seems so

odd to me that plain literals seem to be favoured everywhere, except when
in comes to using XMLLiteral with rdf:parseType="literal", but none of
this is acknowledged or explained anywhere. It looks like using a typed
literal in this one case is accepted merely as a requirement to benefit
from the prettier RDF/XML syntax for XML content. However, I view things
completely in the opposite light. To me, typed literals are a powerful
benefit of RDF. You can use a typed literal to decide how to handle a
literal value, without looking at the value itself, but that advantage is
lost without a sufficiently specific type. Thus, I don't understand how
defining and using a new RDF datatype to identify something as widely
recognized and understood as HTML would impair interoperability. I think
it would do the opposite.

Cheers,
Dave

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the
spec. There was a lot of discussion about this at the time the spec was
under development, but not much of that discussion survived the editorial
process. The only place I see it is in the appendix on standard properties

- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content
and dcterms:description valid XHTML <div> content. This means that the RDF

datatype should be XMLLiteral and that appropriate namespaces should be
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The

parser should propagate that to the content, i.,e. when you look at the
triples, the XML literal node should have the inherited namespace.

If you wanted the namespace directly in the content then you could enclose

the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text.
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of

preview, why would conversion be needed? Shouldn't we be defining content
that is XHTML?

In another use case, people wanted to use native Wiki text as the content.

However, that would cause a big interop problem since there are many Wiki
syntaxes. All of these are convertible to XHTML since that is what the
Wikis do to display the formatted result. In another use case, people
wanted to include Rich Text.

The general theme is that developers want to use whatever native format
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids
conversions. However, this would couple the resource to the tool. OSLC is
trying to achieve interoperability among heterogeneous tools. Therefore a
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF
etc. would mean that OSLC resources would not be understood by other
applications. In general, the creation of new RDF datatypes is discouraged

since it impairs interoperability.

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




Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this

thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of
the more general confusion/discomfort I've been developing over the past
several weeks or months about the use of XMLLiteral with
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not
clear to me who benefits from the use of the unescaped literal
representation, or in what scenario. And that approach, then, requires the

use of the XMLLiteral type, which I also wonder about (as I'll explain
further). If there is some benefit that I don't know about, perhaps it
derails this whole line of thought. But if there isn't, could this be a
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal"
examples were the only ones I could find anywhere in OSLC that use typed
literals (the XMLLiteral type is implicit with this special RDF/XML
syntax). Moreover, I couldn't find any guidance in the specs about the use

of plain vs. typed literals at all. From the perspective of a client,
anyway, it would seem a very nice thing if a particular provider would use

a typed literal to tell you that a title, for example, should be treated
as a simple string or as HTML content. And that's the very thing that
typed literals do. It could be that the presence of an XMLLiteral type is
supposed to signal the use of XHTML content, and the absence of any type
is supposed to signal plain text. But I couldn't find that spelled out
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a
poor job of looking -- and I'd argue it would be better to include types
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral

in the first place. I saw in some old discussions that the intention in
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other

XML languages was considered and endorsed, in principle. But where does
that leave XHTML? With a type that doesn't really say what it is or what
you can do with it. We have specs that communicate the XHMTL intent in
words, but we also have a mechanism built into RDF that could communicate
this, and we're not really using it fully. Thus, I think it would be
preferable to define and use a type that specifically represents HTML. And

note, I suggest HTML, not XHTML, since using any type other than
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal"

syntax. And without that, I don't see a particular benefit in the stricter

XHTML syntax.

One other possibility that I've considered, which Arthur suggested
previously, is using a namespace to identify that the XML is XHTML, in
particular, instead of doing it directly in the literal type. And I
believe that, strictly, the XHTML namespace is required for the elements
to be valid XHTML. But I found no hint of this in the spec or any
examples, and certainly RTC doesn't do this (I haven't checked other
providers). Moreover, I believe it's also a worse approach, since there's
no guarantee that your RDF runtime of choice will give you access to
namespaces declared on the property element (I don't believe Jena does),
and detecting a namespace inside the element content would require
actually parsing the value as XML. If all you want to do is pass markup
along for display in a browser, it would be unfortunate to have to
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a

consumer might actually want to make use of HTML content. Even outside of
the compact rendering scenario, ultimately it's probably going to get
displayed by a browser, whether as part of a larger Web page or in a
browser-backed widget in a rich client. And for that, HTML is probably
just as good as, if not better than, XHTML. Rather than worrying about
whether the content is well-formed XML, it's probably sufficient to just
give it to the browser and see what it can do with it. I would assert that

"something a browser can render" has been the working definition of HTML
for a good number of years now, while XHTML has largely faded in
importance.

Going the other way, the appeal of HTML really shows. If a provider
natively deals with HTML (without concern for XML well-formedness), it
would be attractive to not have to convert that into XHTML to expose it
via OSLC. Likewise, a consumer may use a rich text control that yields
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial,
and it seems unfortunate to impose that conversion task onto everyone,
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid
applying normal XML encoding to markup content (of course, some encoding
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if
they all do make perfect sense (and I'm not necessarily claiming they do),

I realize we may be well past the point of being able to act on them.
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general
would be beneficial. You could even imagine exploiting them as a
compatibility measure, if it was decided that the type of a property
needed to change. This is a related, but separate, topic, which I'd be
thrilled to discuss further, but I don't want to open too many cans of
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML
namespace is required for the elements to

--
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with
XPath, it's the ability to do so in a browser environment. Currently all
implementations of all rich hovers in all Jazz based products encode any
html tags in their dcterms:title attributes (and doubly encode special
characters). For the consumer on the browser side, this means simply
taking the content of the attribute, decoding it (which browsers are very
good at) and slapping the result into the dom (which browsers are also
very good at).

The alternative would be a total consumability nightmare from the point of

view of a browser (which is the most important consumer of this entire
spec). If the tags are actually child nodes in the xml representation, it
means we will have child elements in the resulting document that we get
back from the xml http request which means we will have to traverse a dom
tree and recreate a structure which could easily be represented as an
escaped string, like everyone is doing today.

I realize that implementation is not supposed to lead the spec, but I
don't even think that would be the case here. The oslc compact spec grew
organically out of the old jazz compact rendering spec which can be found
here:

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1

If we look at the semantic description of the dc:title and jp:abbreviation

it states explicitly that the content MUST be escaped:

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;".

This decision was made consciously for very well defined technical reasons

(discussed above) in the original spec. If that decision was reversed in
the creation of the OSLC compact spec then I believe that to have been a
huge mistake and would like to see the spec fixed rather than for all
providers to have to change how their compact documents are served and all

consumers to have to go to the trouble of walking the dom to determine
what the provider is actually trying to show.

Adam Archer
Jazz Developer
IBM Toronto Lab



From: Arthur Ryman/Toronto/IBM
To: Samuel Padgett <spadgett at us.ibm.com>
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>,
"oslc-core at open-services.net" <oslc-core at open-services.net>,
oslc-core-bounces at open-services.net
Date: 08/22/2011 04:40 PM
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup


Sam,

You wrote:

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup
since RDF/XML itselt is very difficult to process using XPath. At one
point we tried to define an OSLC-variant of RDF/XML that looked like
"normal" XML. However, we abandonned that and now require support for
generic RDF/XML.

The are many equivalent ways to represent a given set of triples in
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an
RDF toolkit like Jena.

Regards,
___________________________________________________________________________



Arthur Ryman


DE, PPM Chief Architect

IBM Software, Rational

Toronto Lab | +1-905-413-3077
Twitter | Facebook | YouTube






From:
Samuel Padgett <spadgett at us.ibm.com>
To:
"oslc-core at open-services.net" <oslc-core at open-services.net>
Cc:
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>
Date:
08/07/2011 01:01 PM
Subject:
[oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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/20110826/3a46fedf/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/3a46fedf/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110826/3a46fedf/attachment-0001.gif>

From sspeiche at us.ibm.com  Tue Aug 30 11:50:07 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 30 Aug 2011 11:50:07 -0400
Subject: [oslc-core] REMINDER: OSLC Core WG Meeting Day/Time Survey --
 Please Respond by Sept 1st
Message-ID: <OF5756EEFA.5CE220DA-ON852578FC.0056DC17-852578FC.0056FCA3@us.ibm.com>

If you have not done so, please fill out the survey.  I'm still expecting 
feedback from some people that I haven't seen.

Survey link: http://doodle.com/n5bef5gepvx2fhaw

Using dates 2 weeks from now just as an example.  Pick a day/time of week 
that works, even if it doesn't work for this one week.

Let me know if there are any questions.

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




From ryman at ca.ibm.com  Tue Aug 30 17:45:26 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Tue, 30 Aug 2011 17:45:26 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OF7DB1FCF9.9A95C8CD-ON852578F4.0071A9F9-852578F4.00735D84@ca.ibm.com>
	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
Message-ID: <OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>

Dave,

My point was that when you use rdf:datatype, the content of the element 
must be a string, not XML. When you use rdf:parseType="Literal" the 
content is expected to be XML. In the RDF data model, the lexical space of 
XML consists of well-formed XML fragments, i.e. there is no escaping other 
than that required by XML.

You managed to get the rdf:datatype case to validate by escaping the XML 
markup, i.e. turning it into a string, which seems like unnecessary work 
if you already have an XML fragment.

BTW, I don't understand why the W3C RDF Validation service is displaying 
the XML content as escaped. That means the data is actually 
double-escaped. I'd be happier seeing plain text  N-Triples or Turtle.

It seems to me that since RDF/XML is well-formed XML, then the natural way 
to include XML literals is as XML, not as a string that contains escaped 
XML markup. However, I concede your point that in principle we don't need 
rdf:parseType="Literal"  if you are sure that we get exactly the same set 
of triples using just rdf:datatype. If so, you are correct in saying that 
rdf:parseType="Literal" is just syntactic sugar.

I see where you are going with this. You want OSLC to create a new 
datatype for HTML and you are demonstrating that rdf:datatype gives you 
the mechanism to do this. As I said before, creating a new datatype will 
limit interoperability since other processors will not know how to process 
the new datatype. There is no standard way to define the meaning of a new 
RDF datatype.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 05:31 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Sorry, but I just don't agree. The two links you gave are both to the 
RDF/XML spec, and they describe a special syntax for XMLLiteral-typed 
literals and a general syntax for typed literals. They do not state that 
the general syntax cannot be used for the case of XMLLiteral, and they 
don't say anything that contradicts my understanding of the RDF abstract 
data model.

Indeed, if you follow the "XML literals" link in Section 2.8, the RDF 
Concepts spec defines XMLLiteral, like any other datatype, with a lexical 
space, a value space and a mapping between the two. So, given any XML 
value, what is to prevent you from using that mapping to compute a 
corresponding lexical form, combining it with the datatype URI, and using 
the ordinary literal notation (in any RDF concrete syntax)?

I just tried entering the following two RDF/XML documents into the 
validation service:

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml
"> 12345: <s>Null pointer exception during startup</s></dcterms:title>
</rdf:Description>
</rdf:RDF>

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>
</rdf:Description>
</rdf:RDF>

It yielded exactly the same result in both cases:



I can also confirm Steve's claim that Jena can be configured to write out 
exactly the same triples using either syntax.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 03:58:51 PM---Dave, No, it's not just syntactic 
sugar. You need rdf:parseType="Literal" if you include element con


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/26/2011 03:58 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you 
include element content. If you use rdf:datatype then only character 
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal" 
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince 
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 


Dave Steinberg---08/26/2011 03:22:10 PM---Arthur, I believe you're 
mistaken. I think that parseType="Literal" is just


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/26/2011 03:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just 
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make 
it easy to write literals of this kind"). Either way you write it, you end 
up with the same statement. Two statements with the same subject, the same 
predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same 
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with 
some sort of privileged XMLLiteral representation that couldn't written 
out using any other RDF notation.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the 
content a string that looks like XHTML, i.e. the

From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 


http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 


literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 


There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 


suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 


it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 



Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 


convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 


than at the model level), so I believe that one couldn't use it to produce 


or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 


odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 


- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 


datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 


parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 


the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 


preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 


However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 


since it impairs interoperability.

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




Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 


thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 


use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 


of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 


a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 


in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 


XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 


note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 


syntax. And without that, I don't see a particular benefit in the stricter 


XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 


consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 


"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 


I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 


view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 


it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 


(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 


consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 



Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact



[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format





_______________________________________________
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

_______________________________________________
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




_______________________________________________
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.n et/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






From sspeiche at us.ibm.com  Tue Aug 30 20:33:01 2011
From: sspeiche at us.ibm.com (Steve K Speicher)
Date: Tue, 30 Aug 2011 20:33:01 -0400
Subject: [oslc-core] Fw: [oslc] New URL for OSLC Community Website
Message-ID: <OFB3F74D8C.C0547CD6-ON852578FD.0002F1D1-852578FD.00030641@us.ibm.com>

FYI for those who are not subscribed to the community list.  I recommend 
you weigh in on Core mail list with any spec issues/concerns.

> From: Steve K Speicher/Raleigh/IBM at IBMUS
> To: Kartik Kanakasabesan/Durham/IBM at IBMUS, 
> Cc: community at open-services.net
> Date: 08/30/2011 08:27 PM
> Subject: Re: [oslc] New URL for OSLC Community Website
> Sent by: community-bounces at open-services.net
> 
> +1
> 
> I think this is a good idea.  It has always been awkward to say "the 
OSLC 
> website" and then say "go to open-services.net", they don't exactly 
match 
> each other.  Looking at available domains (not oslc.net, oslc.org, 
> oslc.com) I saw oslc.co being available.  So I think it makes much 
easier 
> to direct people (without having to buy a domain from someone), to "the 
> OSLC website".
> 
> Regarding migration, I think Kartik has pointed out the 
open-services.net 
> is not going away.  The domain names defined in OSLC specs are not 
> changing.  Though, if accepted we could consider using the shorter "
> http://oslc.co" for the spec namespace base for further specs.
> 
> The redirect is active already, so you can go to http://oslc.co
> 
> Thanks,
> Steve Speicher | IBM Rational Software | (919) 254-0645
> 
> > From: Kartik Kanakasabesan/Durham/IBM at IBMUS
> > To: community at open-services.net, 
> > Date: 08/30/2011 02:45 PM
> > Subject: [oslc] New URL for OSLC Community Website
> > Sent by: community-bounces at open-services.net
> > 
> > Hi Folks, 
> >             Wanted to get feedback from the community on this issue. 
We 
> > would like to propose a new URL for the OSLC website, the proposed URL 

> is 
> > OSLC.co  instead of open-services.net. 
> > the .co domain name stands for community and falls in line with effort 

> we 
> > are pushing forward with OSLC. 
> > I would appreciate any thoughts/cocerns/comment on the matter. 
> > We would like to implement this domain change only if the community 
> agree's with it. 
> > Regards, 
> > Kartik _______________________________________________
> > Community mailing list
> > Community at open-services.net
> > http://open-services.net/mailman/listinfo/community_open-services.net
> 
> 
> _______________________________________________
> Community mailing list
> Community at open-services.net
> http://open-services.net/mailman/listinfo/community_open-services.net
> 




From ryman at ca.ibm.com  Wed Aug 31 09:17:38 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Wed, 31 Aug 2011 09:17:38 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OF19022CFD.EBA8C967-ON852578F5.000E9FBB-852578F5.001639CA@ca.ibm.com>
	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>
	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>
	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>
	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
	<OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>
Message-ID: <OF4339B386.01E399CB-ON852578FD.0045DC2C-852578FD.0049075A@ca.ibm.com>

Dave/Randy,

Thx for persisting on this point. It turns out that the W3C RDF Validator 
is in fact displaying markup characters in strings wrong. It is escaping 
them. You can see the correct, unescaped, results by turning on the 
Advanced option of N-Triples output.

This discussion has made me realize that my suggested name for a new 
oslc:htmlEncodedTitle property is misleading. Encoding is only required 
when you put the triple in an XML document., e.g. the OSLC compact 
rendering resource  The encoding is removed by the parser and you end up 
with the unescaped string. Since we are defining RDF predicates, the 
reference to encoding is inappropriate because there is no encoding at the 
RDF value level.

We therefore have the following alternatives for markup in the title:

1. Use XML Literal datatype and XHTML content.
2. Define a new datatype for HTML
3. Define a new predicate for HTML titles, e.g. oslc:htmlTitle

Using HTML within the context of the UI preview is OK since the UI is 
expected to be a web UI and you'd just copy the string.

However, I think using HTML in RDF is not a good idea because all readers 
of the data would then have to cope with it, I mentioned that Tidy could 
be used by the writer of the data to convert it to XHTML. That does not 
mean this is practical for all readers of the data. In general, when you 
are designing a format for interoperability, you should convert diverse 
formats into one common format. We should therefore adopt XHTML as the one 
common format for marked up text interchange.

Recall that HTML is only one alternate format. We also have sources that 
produce rich text (RTF), and wiki text. Agreeing on XHTML is a useful 
simplification.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Dave Steinberg/Toronto/IBM at IBMCA
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/30/2011 05:49 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

My point was that when you use rdf:datatype, the content of the element 
must be a string, not XML. When you use rdf:parseType="Literal" the 
content is expected to be XML. In the RDF data model, the lexical space of 

XML consists of well-formed XML fragments, i.e. there is no escaping other 

than that required by XML.

You managed to get the rdf:datatype case to validate by escaping the XML 
markup, i.e. turning it into a string, which seems like unnecessary work 
if you already have an XML fragment.

BTW, I don't understand why the W3C RDF Validation service is displaying 
the XML content as escaped. That means the data is actually 
double-escaped. I'd be happier seeing plain text  N-Triples or Turtle.

It seems to me that since RDF/XML is well-formed XML, then the natural way 

to include XML literals is as XML, not as a string that contains escaped 
XML markup. However, I concede your point that in principle we don't need 
rdf:parseType="Literal"  if you are sure that we get exactly the same set 
of triples using just rdf:datatype. If so, you are correct in saying that 
rdf:parseType="Literal" is just syntactic sugar.

I see where you are going with this. You want OSLC to create a new 
datatype for HTML and you are demonstrating that rdf:datatype gives you 
the mechanism to do this. As I said before, creating a new datatype will 
limit interoperability since other processors will not know how to process 

the new datatype. There is no standard way to define the meaning of a new 
RDF datatype.

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/26/2011 05:31 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Sorry, but I just don't agree. The two links you gave are both to the 
RDF/XML spec, and they describe a special syntax for XMLLiteral-typed 
literals and a general syntax for typed literals. They do not state that 
the general syntax cannot be used for the case of XMLLiteral, and they 
don't say anything that contradicts my understanding of the RDF abstract 
data model.

Indeed, if you follow the "XML literals" link in Section 2.8, the RDF 
Concepts spec defines XMLLiteral, like any other datatype, with a lexical 
space, a value space and a mapping between the two. So, given any XML 
value, what is to prevent you from using that mapping to compute a 
corresponding lexical form, combining it with the datatype URI, and using 
the ordinary literal notation (in any RDF concrete syntax)?

I just tried entering the following two RDF/XML documents into the 
validation service:

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml
"> 12345: <s>Null pointer exception during startup</s></dcterms:title>
</rdf:Description>
</rdf:RDF>

<rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.com/bugs/2314">
<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>
</rdf:Description>
</rdf:RDF>

It yielded exactly the same result in both cases:



I can also confirm Steve's claim that Jena can be configured to write out 
exactly the same triples using either syntax.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 03:58:51 PM---Dave, No, it's not just syntactic 
sugar. You need rdf:parseType="Literal" if you include element con


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/26/2011 03:58 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

No, it's not just syntactic sugar. You need rdf:parseType="Literal" if you 

include element content. If you use rdf:datatype then only character 
content is allowed.

This is explained in the spec at [1] and [2]. rdf:parseType="Literal" 
allows XML Literal content. rdf:datatype="whatever" allows string content.

However, since specs are hard to understand, I suggest you convince 
yourself of this, as I did, by using the W3C RDF Validation service. [3]

[1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
[2] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
[3] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 


Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 


Dave Steinberg---08/26/2011 03:22:10 PM---Arthur, I believe you're 
mistaken. I think that parseType="Literal" is just


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/26/2011 03:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Arthur,

I believe you're mistaken. I think that parseType="Literal" is just 
syntactic sugar (RDF Primer: "RDF/XML provides a special notation to make 
it easy to write literals of this kind"). Either way you write it, you end 

up with the same statement. Two statements with the same subject, the same 

predicate and a typed literal with the same type (<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>) and the same 
lexical form are indistinguishable.

Also, if you were correct, parseType="Literal" would provide RDF/XML with 
some sort of privileged XMLLiteral representation that couldn't written 
out using any other RDF notation.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
905-413-3705
davidms at ca.ibm.com


Arthur Ryman---08/26/2011 02:22:29 PM---Randy, Your example makes the 
content a string that looks like XHTML, i.e. the

From:

Arthur Ryman/Toronto/IBM

To:

Randy Hudson/Raleigh/IBM at IBMUS

Cc:

Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net

Date:

08/26/2011 02:22 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup



Randy,

Your example makes the content a string that looks like XHTML, i.e. the 
content contains no XHTML elements since all the markup characters are 
encoded. A string is simply parsed character data and is valid XML.

The correct way to include the XHTML elements is:

<dcterms:title rdf:parseType="Literal"> 12345: <s xmlns="
http://www.w3.org/1999/xhtml">Null pointer exception during 
startup</s></dcterms:title>

The OSLC Guidelines about escaping are for the case where you need to 
include characters that might get misinterpreted as XML markup. For 
example, consider a math statement like "1 < 2". When you put that in an 
XML element, you need to encode it as "1 &lt; 2"

Regards, 
___________________________________________________________________________ 



Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Randy Hudson/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
Dave Steinberg <davidms at ca.ibm.com>, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
08/25/2011 07:06 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup


The following input is also equivalent:

<dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"> 12345: &lt;s 
xmlns="http://www.w3.org/1999/xhtml"&gt;Null pointer exception during 
startup&lt;/s&gt;</dcterms:title>

So there are (at least) two different ways to serialize a property value 
of type XML literal.  But, the OSLC guidelines state:

1.2 If property value is a Literal value-type 
1.2.1 Inside the XML element add the value as a string with any required 
escaping 

That would seem to suggest that the above form should be used.

-Randy




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Dave Steinberg <davidms at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
08/25/2011 04:34 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Dave,

1. XML Namespaces. 

RDF/XML is well-formed XML so it must support namespaces correctly. For 
triples whose datatype is XML Literal, the value of this literal is a 
well-formed XML fragment, and therefore the namespaces should be present 
in the content. If there is an enclosing <span> element, then the 
namespace should be there. Otherwise, each element in the content should 
have the namespace. 

The spec doesn't say "for XHTML, you need to insert an xmlns attribute for 



http://www.w3.org/1999/xhtml" because that is part of the XHTML standard, 
i.e. it's not XHTML unless the elements are in the XHTML namespace. 

2. Jena

I loaded the sample RDF/XML  into Fuseki which uses Jena and it produced 
the correct result. I assume the Jena API lets you get an XML DOM from the 



literal value.

The input contained:    <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml"> 12345: <s>Null pointer exception during 
startup</s> </dcterms:title>

The output value is:   " 12345: <s xmlns="http://www.w3.org/1999/xhtml
">Null pointer exception during startup</s> "^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral>

3.  XHTML versus HTML

The primary reason is that RDF supports XHTML via the XMLLiteral datatype. 



There is no parsing support for HTML built into RDF.

Another strong reason is that the syntax of HTML is very irregular and 
hard to parse correctly - that is one of the reasons XML was invented. 
This is very important from a security viewpoint. To guard against script 
injection attacks, you really should parse the input and remove any 
<script> elements or Javascript attributes. Doing that correctly for HTML 
requires a full HTML parser. On the other hand, the XHTML is given to you 
as a DOM which you can easily traverse or process using XSLT or XPATH.

4. Datatypes

The specs do specify the datatypes for some properties. Look at the 
Value-Type column of the tables, e.g. [1]. You need to include the 
datatype explicitly for ints, dates, XML. etc. You specify that using 
rdf:datatype in RDF/XML, or using ^^ in Turtle. 

I don't know what the state of adoption is. We really should get some test 



suites written for the specs.

5. Inventing new Datatypes

The RDF spec defines the XSD datatypes and the XMLLiteral datatype. RDF 
parsers know how to parse those. If someone introduces a new datatype URI, 



it could break parsers since they won't know how to parse the contents. 
There is no standard way to define new datatypes. 

Try it with the RDF Validation service [2]

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA
[2] http://www.w3.org/RDF/Validator/

Regards, 
___________________________________________________________________________ 




Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:
Dave Steinberg/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
08/24/2011 03:05 PM
Subject:
Re: [oslc-core] OSLC Compact representation, titles with markup
Sent by:
oslc-core-bounces at open-services.net



Hi Arthur,

Thanks for the response. Apologies for being slow in replying; I've been 
out sick for the last day and a half.

I agree that putting the XML namespace on the enclosing element would be a 



convenience, but only if tools supported that. As far as I could find, 
Jena provides no fine-grained access to namespace declarations (i.e. other 



than at the model level), so I believe that one couldn't use it to produce 



or consume the fragment that you suggested. Moreover, the other RDF 
representations offer no such convenience, even in theory.

So, it seems to me that the suggestion to use a namespace was actually a 
pretty significant one, and not one that's reflected in the specs, since 
you'd always need an enclosing element for your XML content.

Thanks for the suggestion of using Tidy to convert from HTML to XHTML. 
That was very helpful for me. But I must admit, I'm still left wondering 
what makes XHTML superior to HTML for interchanging formatted text, 
especially in light of the compact representation example and my own 
experiences, where the opposite seems to be true.

One last thing that I'll emphasize is that I mentioned a lack of guidance 
in the OSLC specs specifically about plain vs. typed literals. It seems so 



odd to me that plain literals seem to be favoured everywhere, except when 
in comes to using XMLLiteral with rdf:parseType="literal", but none of 
this is acknowledged or explained anywhere. It looks like using a typed 
literal in this one case is accepted merely as a requirement to benefit 
from the prettier RDF/XML syntax for XML content. However, I view things 
completely in the opposite light. To me, typed literals are a powerful 
benefit of RDF. You can use a typed literal to decide how to handle a 
literal value, without looking at the value itself, but that advantage is 
lost without a sufficiently specific type. Thus, I don't understand how 
defining and using a new RDF datatype to identify something as widely 
recognized and understood as HTML would impair interoperability. I think 
it would do the opposite.

Cheers,
Dave

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Arthur Ryman---08/23/2011 10:09:55 AM---Dave, Thx for the comments.


From:

Arthur Ryman/Toronto/IBM

To:

Dave Steinberg/Toronto/IBM at IBMCA

Cc:

oslc-core at open-services.net, oslc-core-bounces at open-services.net

Date:

08/23/2011 10:09 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup


Dave,

Thx for the comments.

I agree that the guidance on using XMLLiteral is not very clear in the 
spec. There was a lot of discussion about this at the time the spec was 
under development, but not much of that discussion survived the editorial 
process. The only place I see it is in the appendix on standard properties 



- dcterms:title and dcterms:description. [1]

The guidance was that dcterms:title should be valid XHTML <span> content 
and dcterms:description valid XHTML <div> content. This means that the RDF 



datatype should be XMLLiteral and that appropriate namespaces should be 
used for XHTML content.

Putting the XHTML namespace on the enclosing element is a convenience. The 



parser should propagate that to the content, i.,e. when you look at the 
triples, the XML literal node should have the inherited namespace. 

If you wanted the namespace directly in the content then you could enclose 



the content in a <div> or <span> and put the namespace there.

Using XHTML is the best way to achieve interchange of formatted text. 
There are converter from HTML to XHTML, e.g. Tidy. However, in the case of 



preview, why would conversion be needed? Shouldn't we be defining content 
that is XHTML?

In another use case, people wanted to use native Wiki text as the content. 



However, that would cause a big interop problem since there are many Wiki 
syntaxes. All of these are convertible to XHTML since that is what the 
Wikis do to display the formatted result. In another use case, people 
wanted to include Rich Text.

The general theme is that developers want to use whatever native format 
their tool supports, e,g, HTML, wiki text, and Rich Text, since it avoids 
conversions. However, this would couple the resource to the tool. OSLC is 
trying to achieve interoperability among heterogeneous tools. Therefore a 
common rich text format is needed.

The alternative of defining new RDF datatypes for HTML, wiki text, RTF 
etc. would mean that OSLC resources would not be understood by other 
applications. In general, the creation of new RDF datatypes is discouraged 



since it impairs interoperability.

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





Regards, 
___________________________________________________________________________ 




Arthur Ryman 


DE, PPM Chief Architect

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube




Dave Steinberg---08/23/2011 12:06:32 AM---Hi all, I've been following this 



thread with interest, as it touches on some of the


From:

Dave Steinberg/Toronto/IBM at IBMCA

To:

oslc-core at open-services.net

Date:

08/23/2011 12:06 AM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



Hi all,

I've been following this thread with interest, as it touches on some of 
the more general confusion/discomfort I've been developing over the past 
several weeks or months about the use of XMLLiteral with 
rdf:parseType="Literal" for HTML content.

Adam's comments below are particularly interesting. In general, it's not 
clear to me who benefits from the use of the unescaped literal 
representation, or in what scenario. And that approach, then, requires the 



use of the XMLLiteral type, which I also wonder about (as I'll explain 
further). If there is some benefit that I don't know about, perhaps it 
derails this whole line of thought. But if there isn't, could this be a 
case of the concrete representation tail wagging the abstract syntax dog?

One thing that always struck me as odd was that rdf:parseType="Literal" 
examples were the only ones I could find anywhere in OSLC that use typed 
literals (the XMLLiteral type is implicit with this special RDF/XML 
syntax). Moreover, I couldn't find any guidance in the specs about the use 



of plain vs. typed literals at all. From the perspective of a client, 
anyway, it would seem a very nice thing if a particular provider would use 



a typed literal to tell you that a title, for example, should be treated 
as a simple string or as HTML content. And that's the very thing that 
typed literals do. It could be that the presence of an XMLLiteral type is 
supposed to signal the use of XHTML content, and the absence of any type 
is supposed to signal plain text. But I couldn't find that spelled out 
anywhere -- if it is, perhaps it's hard to find, or perhaps I just did a 
poor job of looking -- and I'd argue it would be better to include types 
in both cases. [1]

It's this line of thinking that leads me to question the use of XMLLiteral 



in the first place. I saw in some old discussions that the intention in 
OSLC was not for XMLLiteral to imply XHTML necessarily. Using it for other 



XML languages was considered and endorsed, in principle. But where does 
that leave XHTML? With a type that doesn't really say what it is or what 
you can do with it. We have specs that communicate the XHMTL intent in 
words, but we also have a mechanism built into RDF that could communicate 
this, and we're not really using it fully. Thus, I think it would be 
preferable to define and use a type that specifically represents HTML. And 



note, I suggest HTML, not XHTML, since using any type other than 
XMLLiteral eliminates the "benefit" of the special rdf:parseType="Literal" 



syntax. And without that, I don't see a particular benefit in the stricter 



XHTML syntax.

One other possibility that I've considered, which Arthur suggested 
previously, is using a namespace to identify that the XML is XHTML, in 
particular, instead of doing it directly in the literal type. And I 
believe that, strictly, the XHTML namespace is required for the elements 
to be valid XHTML. But I found no hint of this in the spec or any 
examples, and certainly RTC doesn't do this (I haven't checked other 
providers). Moreover, I believe it's also a worse approach, since there's 
no guarantee that your RDF runtime of choice will give you access to 
namespaces declared on the property element (I don't believe Jena does), 
and detecting a namespace inside the element content would require 
actually parsing the value as XML. If all you want to do is pass markup 
along for display in a browser, it would be unfortunate to have to 
actually parse the content to determine that it's XHTML.

And this is where I close the loop on my thinking, by coming back to how a 



consumer might actually want to make use of HTML content. Even outside of 
the compact rendering scenario, ultimately it's probably going to get 
displayed by a browser, whether as part of a larger Web page or in a 
browser-backed widget in a rich client. And for that, HTML is probably 
just as good as, if not better than, XHTML. Rather than worrying about 
whether the content is well-formed XML, it's probably sufficient to just 
give it to the browser and see what it can do with it. I would assert that 



"something a browser can render" has been the working definition of HTML 
for a good number of years now, while XHTML has largely faded in 
importance.

Going the other way, the appeal of HTML really shows. If a provider 
natively deals with HTML (without concern for XML well-formedness), it 
would be attractive to not have to convert that into XHTML to expose it 
via OSLC. Likewise, a consumer may use a rich text control that yields 
HTML. Generalized parsing of HTML for conversion to XHTML is non-trivial, 
and it seems unfortunate to impose that conversion task onto everyone, 
just so that we can use rdf:parseType="Literal" in RDF/XML and avoid 
applying normal XML encoding to markup content (of course, some encoding 
will likely be required for other RDF syntaxes anyway).

So, those are my thoughts on this (admittedly enlarged) topic. Even if 
they all do make perfect sense (and I'm not necessarily claiming they do), 



I realize we may be well past the point of being able to act on them. 
Still, I thought I'd put them out there and see what others make of them.

Cheers,
Dave


[1] In fact, I think that the consistent use of typed literals in general 
would be beneficial. You could even imagine exploiting them as a 
compatibility measure, if it was decided that the type of a property 
needed to change. This is a related, but separate, topic, which I'd be 
thrilled to discuss further, but I don't want to open too many cans of 
worms at once.

[2] Or, perhaps, a less kind way of putting that is that the XHTML 
namespace is required for the elements to 

-- 
Dave Steinberg
IBM Rational Software
davidms at ca.ibm.com


Adam Archer---08/22/2011 06:20:05 PM---The big concern to me is not the 
ability to process the RDF/XML with XPath, it's the ability to do

From:

Adam Archer/Toronto/IBM at IBMCA

To:

Arthur Ryman/Toronto/IBM at IBMCA

Cc:

"oslc-core at open-services.net" <oslc-core at open-services.net>, Randy Hudson 
<hudsonr at us.ibm.com>, oslc-core-bounces at open-services.net

Date:

08/22/2011 06:20 PM

Subject:

Re: [oslc-core] OSLC Compact representation, titles with markup

Sent by:

oslc-core-bounces at open-services.net



The big concern to me is not the ability to process the RDF/XML with 
XPath, it's the ability to do so in a browser environment. Currently all 
implementations of all rich hovers in all Jazz based products encode any 
html tags in their dcterms:title attributes (and doubly encode special 
characters). For the consumer on the browser side, this means simply 
taking the content of the attribute, decoding it (which browsers are very 
good at) and slapping the result into the dom (which browsers are also 
very good at). 

The alternative would be a total consumability nightmare from the point of 



view of a browser (which is the most important consumer of this entire 
spec). If the tags are actually child nodes in the xml representation, it 
means we will have child elements in the resulting document that we get 
back from the xml http request which means we will have to traverse a dom 
tree and recreate a structure which could easily be represented as an 
escaped string, like everyone is doing today. 

I realize that implementation is not supposed to lead the spec, but I 
don't even think that would be the case here. The oslc compact spec grew 
organically out of the old jazz compact rendering spec which can be found 
here: 

https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 

If we look at the semantic description of the dc:title and jp:abbreviation 



it states explicitly that the content MUST be escaped: 

> The HTML markup MUST be escaped; for example, "<b>" as "&lt;b&gt;". 

This decision was made consciously for very well defined technical reasons 



(discussed above) in the original spec. If that decision was reversed in 
the creation of the OSLC compact spec then I believe that to have been a 
huge mistake and would like to see the spec fixed rather than for all 
providers to have to change how their compact documents are served and all 



consumers to have to go to the trouble of walking the dom to determine 
what the provider is actually trying to show. 

Adam Archer
Jazz Developer
IBM Toronto Lab 



From: Arthur Ryman/Toronto/IBM 
To: Samuel Padgett <spadgett at us.ibm.com> 
Cc: Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com>, 
"oslc-core at open-services.net" <oslc-core at open-services.net>, 
oslc-core-bounces at open-services.net 
Date: 08/22/2011 04:40 PM 
Subject: Re: [oslc-core] OSLC Compact representation, titles with markup 


Sam, 

You wrote: 

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"

I don't think problems using XPath are a valid reason to encode markup 
since RDF/XML itselt is very difficult to process using XPath. At one 
point we tried to define an OSLC-variant of RDF/XML that looked like 
"normal" XML. However, we abandonned that and now require support for 
generic RDF/XML. 

The are many equivalent ways to represent a given set of triples in 
RDF/XML. It would therefore be very problematic to use XPath, XSLT, or 
XQuery to process RDF/XML. The safe way to process RDF/XML is to use an 
RDF toolkit like Jena. 

Regards, 
___________________________________________________________________________ 




Arthur Ryman 


DE, PPM Chief Architect 

IBM Software, Rational 

Toronto Lab | +1-905-413-3077 
Twitter | Facebook | YouTube






From: 
Samuel Padgett <spadgett at us.ibm.com> 
To: 
"oslc-core at open-services.net" <oslc-core at open-services.net> 
Cc: 
Adam Archer/Toronto/IBM at IBMCA, Randy Hudson <hudsonr at us.ibm.com> 
Date: 
08/07/2011 01:01 PM 
Subject: 
[oslc-core] OSLC Compact representation, titles with markup 
Sent by: 
oslc-core-bounces at open-services.net





I believe the spec is a bit confusing when it comes to titles with markup
for UI Preview.

The Compact representation has a dcterms:title property. It's defined as 
an
XML Literal that can contain XHTML markup [1]. My understanding of XML
Literals as discussed in the RDF Primer [2] means a title with markup 
would
look like this,

<dcterms:title>12345: <s>Null pointer exception during
startup</s></dcterms:title>

The example [3] of this resource has a title like this, however,

<dcterms:title> 12345: &lt;s&gt;Null pointer exception during
startup&lt;/s&gt; </dcterms:title>

The example doesn't seem to fit with the description.

It's very difficult to parse the former using XPath. For instance, the
expression "/oslc:Compact/dcterms:title" takes out the "<s>" and "</s>"
Most implementations I'm aware also follow the example where markup is
encoded. It means special characters need to be "double encoded." For
instance, "12345: Values > 1000 incorrectly calculated" would be,

<dcterms:title>12345: Values &amp;gt; 1000 incorrectly
calculated</dcterms:title>

I think we should add more clarity to the spec here, as getting this wrong
can open up consumers to cross-site scripting attacks. I'd also suggest we
say that providers MUST NOT use any markup with a <script> tag and 
consumer
MUST NOT display any markup with a <script> tag to guard against this
problem.

Best Regards,
Sam


[1]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#Representation_Compact




[2] http://www.w3.org/TR/rdf-syntax/#xmlliterals
[3]
http://open-services.net/bin/view/Main/OslcCoreUiPreview?sortcol=table;up=#XML_Representation_Format






_______________________________________________
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

_______________________________________________
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




_______________________________________________
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.n et/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




_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net






From ryman at ca.ibm.com  Wed Aug 31 11:03:06 2011
From: ryman at ca.ibm.com (Arthur Ryman)
Date: Wed, 31 Aug 2011 11:03:06 -0400
Subject: [oslc-core] OSLC Compact representation, titles with markup
In-Reply-To: <OF4339B386.01E399CB-ON852578FD.0045DC2C-852578FD.0047AE42@LocalDomain>
References: <OF7A22AD33.4D766C72-ON852578E5.00590EAF-852578E5.005D7536@us.ibm.com>	<OFCBEF16DD.2A136587-ON852578F5.004C019F-852578F5.004DCD83@LocalDomain>
	<OF51160EBB.7B18469D-ON852578F6.0064241C-852578F6.00687E9A@ca.ibm.com>	<OFA9BF05B6.E3575AC8-ON852578F7.00620995-852578F7.0070CD5F@ca.ibm.com>
	<OFEAC96D27.D7EE9301-ON852578F7.007DEB9C-852578F7.007EF602@LocalDomain>	<OF8B5FA9F5.D78E89C9-ON852578F8.0062B7D3-852578F8.0064F0BB@LocalDomain>
	<OFF4042EA2.060F596E-ON852578F8.00697717-852578F8.006A4C0F@ca.ibm.com>	<OF71B3B92A.45D53013-ON852578F8.006C85DA-852578F8.006D45BF@LocalDomain>
	<OFEDE5D3D4.9614747B-ON852578F8.007300F1-852578F8.0076366B@ca.ibm.com>
	<OFB7E9C3F3.3DA949BA-ON852578FC.00746EB7-852578FC.0077929F@ca.ibm.com>
	<OF4339B386.01E399CB-ON852578FD.0045DC2C-852578FD.0047AE42@LocalDomain>
Message-ID: <OF78BCA281.77E9C908-ON852578FD.005090E8-852578FD.0052AEFA@ca.ibm.com>

Dave/Randy,

I was wrong in saying that rdf:parseType="Literal" was required. I 
verified your statement that rdf:parseType="Literal" is syntactic sugar 
for a corresponding rdf:datatype attribute by using the jena.rdfcopy 
utility which converts RDF/XML to N-TRIPLE. The W3C RDF Validation service 
was erroneously escaping markup on output. The escaping is just an 
artifact of XML and is not part of the lexical space of RDF literal 
values. I am including an RDF/XML document and its N-TRIPLE equivalent.

Note that subjects 3 and 4 have identical objects.

RDF/XML

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dcterms="http://purl.org/dc/terms/">

<rdf:Description rdf:about="http://example.com/subject/1">
   <dcterms:title>1 &lt; 2</dcterms:title>
</rdf:Description>

<rdf:Description rdf:about="http://example.com/subject/2">
   <dcterms:title rdf:parseType="Literal" xmlns="
http://www.w3.org/1999/xhtml">This is 
<s>strikethrough</s>.</dcterms:title>
</rdf:Description>

<rdf:Description rdf:about="http://example.com/subject/3">
   <dcterms:title rdf:parseType="Literal">This is 
<s>strikethrough</s>.</dcterms:title>
</rdf:Description>

<rdf:Description rdf:about="http://example.com/subject/4">
   <dcterms:title rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">This is 
&lt;s&gt;strikethrough&lt;/s&gt;.</dcterms:title>
</rdf:Description>

</rdf:RDF>

N-TRIPLE

<http://example.com/subject/1> <http://purl.org/dc/terms/title> "1 < 2" .
<http://example.com/subject/2> <http://purl.org/dc/terms/title> "This is 
<s xmlns=\"http://www.w3.org/1999/xhtml\">strikethrough</s>."^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .
<http://example.com/subject/3> <http://purl.org/dc/terms/title> "This is 
<s>strikethrough</s>."^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .
<http://example.com/subject/4> <http://purl.org/dc/terms/title> "This is 
<s>strikethrough</s>."^^<
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 



Arthur Ryman/Toronto/IBM wrote on 08/31/2011 09:02:56 AM:

> [image removed] 
> 
> Re: [oslc-core] OSLC Compact representation, titles with markup 
> 
> Arthur Ryman 
> 
> to:
> 
> Dave Steinberg
> 
> 08/31/2011 09:02 AM
> 
> Cc:
> 
> oslc-core, oslc-core-bounces
> 
> Dave/Randy,
> 
> Thx for persisting on this point. It turns out that the W3C RDF 
> Validator is in fact displaying markup characters in strings wrong. 
> It is escaping them. You can see the correct, unescaped, results by 
> turning on the Advanced option of N-Triples output.
>