Re: Updated rationale for RDFCore's current design

In thinking a bit more about things, and discussing it with
others, I realized that I would be particularly interested
in the answer to my following question:

At 18:14 03/07/08 -0400, Martin Duerst wrote:

>At 18:48 03/07/08 +0100, Brian McBride wrote:

>>2. RDFCore agrees with feedback that it received, that
>>building an XML specific mechanism into its core model is architecturaly
>>inappropriate - it mixes things that should be independent.  Accepting
>>this implies that parseType="Literal" values must use one of the
>>existing mechanisms - i.e. either plain literals or typed literals, or a
>>new more general mechanism must be invented, e.g. a new triple
>>structure.  An XML specific mechanism is undesirable.
>
>- Who gave you this feedback, and how did they justify it?

I'm particularly interested in an answer to this question because
I think RDF Core could have simply said that literals containing
XML were part of M&S, and the RDF Core WG was not chartered to
change that, and that RDF Core had an agreement with I18N to
keep language information.

I'm also interested because it is difficult to agree or disagree
with the above without knowing the background.

I'm also curious as to what extent RDF (in M&S or later) actually
creates XML-specific mechanisms, on and above the language information
(already existing in plain literals, and not really XML-specific)
and datatyping (based on XML Schema, and very much influenced
by the need to textually serialize data). I also wonder whether
squeezing XML literals into the straightjacket of simple datatypes
isn't a greater architectural appropriateness.
[I understand the wish to associate complex types with XML literals,
but I doubt that this will be as easy as some people have claimed.
Simple types and complex types are quite different in XML Schema,
definitely more different than I18N would have them liked to be.]

Regards,    Martin.

Received on Thursday, 10 July 2003 00:54:43 UTC