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

[Dave Steinberg]

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:
<s>Null pointer exception during startup</s></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>