[oslc-core] Need for an XML literal value type

Fri Mar 19 13:49:33 EDT 2010

Hello Dave,
What pressure is there for core to constrain the use of rdf literals typed as xmlliteral?

I'd prefer to leave any such constraints to the domain specs

Regards
-ian

----- Original Message -----
From: Dave [snoopdave at gmail.com]
Sent: 19/03/2010 13:26 AST
To: oslc-core at open-services.net
Subject: Re: [oslc-core] Need for an XML literal value type

Arthur, thanks for your patience and good answers. I think I'm convinced.

I do have a couple more questions for the WG:

- Should we offer any guidance to folks who wish to store HTML5 or
HTML 4.0.1 content as a property value?

- Instead of an "XML Literal" value-type, what if we allowed only
"XHTML Literal"? -- thus allowing literal XML only for rich text.

Thanks,
- Dave

On Fri, Mar 19, 2010 at 12:30 PM, Arthur Ryman <ryman at ca.ibm.com> wrote:
> Dave,
>
> The data model that OSLC is adopting is RDF. We therefore need to define
> how to represent RDF in various formats. There are some native RDF
> formats, like N3 and Turtle - no problem there. For putting RDF in XML we
> use RDF/XML which is just as much a standard as RDF itself.
>
> In RDF/XML, the way you include XML literal values is via the attribute
> rdf:parseType="Literal" [1]. RDF defines a datatype for literal XML [2].
> This lets us put the angle brackets etc. in the RDF/XML document, and the
> result is a well-formed XML document which is also RDF/XML valid, and we
> can process the literal XML normally.
>
> When we define how to represent RDF as JSON, we need to define how to
> represent the literal values. An XML literal would be encoded in JSON as a
> string, but that string would be valid XML. What problem do you see in
> having a JSON value that contains a valid XML string?
>
> Your proposal to use xsd:string for literal XML would require us to escape
> all the parser-significant  XML characters, which hides the fact that the
> content is XML and defeats processing by standard XML tools (e.g XSLT) and
> would make integration with other RDF data problematic, i.e. how would
> other applications know that xsd:string values needs to be unescaped? How
> would we distinguish strings that were plain text (and might contain angle
> brackets) from text that was really esacped XML?
>
> The background for rich text is that many tools allow users to enter rich
> text and include that in their resource representations. This is
> especially important for Requirements tools where people do spend effort
> to highlight text, e.g. in red, to indicate some semantics. The place
> XHTML comes in is as an interchange format, i.e. OSLC resource should use
> XHTML for rich text. Each tool must convert it's native format to XHTML
> for purposes of interchange via OSLC resources. Uses would not type in
> XHTML directly. They would use editors provided by the tools, and the
> tools would convert it to XHTML for interchange.
>
> In the specific cases of dc:title and dc:description, we should use <span>
> and <div> content respectively. A JSON client that received these literal
> values can simply set or get this as DOM element content  via the
> innerHTML property.
>
> I'd be happy to have a telecon with you to discuss this further.
>
> [1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-XML-literals
> [2]
> http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-rdf-XMLLiteral
>
> Regards,
> ___________________________________________________________________________
>
> Arthur Ryman, PhD, DE
>
>
> Chief Architect, Project and Portfolio Management
>
> IBM Software, Rational
>
> Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
> Twitter | Facebook | YouTube
>
>
>
>
>
>
>
> From:
> Dave <snoopdave at gmail.com>
> To:
> Arthur Ryman/Toronto/IBM at IBMCA
> Date:
> 03/19/2010 09:53 AM
> Subject:
> Re: [oslc-core] Need for an XML literal value type
>
>
>
> On Thu, Mar 18, 2010 at 10:40 PM, Arthur Ryman <ryman at ca.ibm.com> wrote:
>> Please explain why you are concerned. Literal XML is a standard feature
> of RDF.
>
> Thanks for the helpful explanations, Steve, Ian and Arthur.
>
> I guess I still don't understand the need for XML literal in OSLC.
> XHTML can be stored as a string -- so, what are the advantages of
> storing it as literal XML? What specifically does XML literal buy us
> over using a simple string?
>
> I'm concerned here because I'd like to see non-XML representations on
> equal footing and I'd like to encourage folks to express things as
> property values and not as XML constructs. Allowing literal XML could
> open the door to XML content in places other than this XHTML case and
> that could be an issue for JavaScript developers expecting JSON and
> not wanting to ever have to parse XML.
>
> I also had concerns about embedding XML in property values because it
> would result in invalid RDF/XML, but apparently the parse-type literal
> makes this possible. Ian Green's comments seem to contradict this. Do
> we have a definitive answer here?
>
> Thanks,
> - Dave
>
>
>>
>> The pro for XML literal values is that we are using RDF in the way it
> was
>> designed. OSLC data may be combined with RDF data from other sources so
> we
>> should adhere to the standard. We do not want to create an OSLC dialect
> of
>> RDF.
>>
>> For rich text, we should adopt XHTML as the standard interchange format,
>> and we should transfer it in RDF/XML as literal XML, not obfuscate it by
>> turning it into a string.
>>
>> Many development tools capture rich text. Adopting a standard rich text
>> format for OSLC, i.e. XHTML, simplifies processing (e.g. inclusion of
> rich
>> text in UIs, documents and reports) and interchange (so tools only have
> to
>> understand one format as opposed to understand RTF, HTML, etc.). XHTML
> has
>> a simpler syntax than HTML and is XML compliant so it can be readily
>> processed by many XML technologies.
>>
>> In addition, there are other good reasons for using XML in general as
> the
>> value of a property, e.g. when there is an existing XML format, or when
>> plain old XML is a more natural way to represent a literal value
>> (otherwise you get an explosion of blank nodes).
>>
>> Regards,
>>
> ___________________________________________________________________________
>>
>> Arthur Ryman, PhD, DE
>>
>>
>> Chief Architect, Project and Portfolio Management
>>
>> IBM Software, Rational
>>
>> Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
>> Twitter | Facebook | YouTube
>>
>>
>>
>>
>>
>>
>>
>> From:
>> Dave <snoopdave at gmail.com>
>> To:
>> oslc-core at open-services.net
>> Date:
>> 03/18/2010 09:26 AM
>> Subject:
>> [oslc-core] Need for an XML literal value type
>> Sent by:
>> oslc-core-bounces at open-services.net
>>
>>
>>
>> I'm still a little concerned about adding XML literal as a value type
>> and I'm trying to understand the pros and cons. The only justification
>> that we have so far for adding an XML literal value is for storing
>> XHTML data, which we need for rich text, but we can easily store XHTML
>> data as a string.
>>
>> What specifically do we gain by putting XHTML content in-line in our
>> RDF/XML and Atom XML representations?
>>
>> And conversely, what do we lose by not doing so?
>>
>> Also, does putting XHTML content in-line in RDF/XML result in valid
>> RDF/XML?
>>
>> Thanks,
>> - Dave
>>
>> _______________________________________________
>> 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