RE: rdfms-literal-is-xml-structure: Why?

Brian said:

> I was thinking of [...]
> 
>   struct {
>     String  string;
>     String  lang;
>     boolean wellFormed;
>     Set     namespaces;
>   }
> 
> so the object that represents a literal would know
> what namespaces and their prefixes are.  I think
> this is similar/same to/as you are suggesting.

Looks good to me.

> what did the original wg
> have in mind when they added parseType="literal" to the spec.
> I suspect that they just wanted a convenient way of representing
> markup as a string without having to to escape all those < chars.

Pretty much. If memory serves, there was also some concern
about knowing when the &lt; was and was not supposed to be XML.
But this was something that was added very late - after the
working group last call in fact. I recall it being mostly
because of one member's concern about internationalization -
BiDi and Ruby I suppose.

In fact the spec notes that parseType='Literal' is not expected
to be the last word on the subject.

> Did the working group realise that parseType="Literal" introduced
> a new kind of literal into the model.  Was that the intent?

I don't know that it was explicitly acknowledged, but that
is effectively the intent because of the &lt; issue mentioned
above.

> I kinda take issue with the repeated claims that xml:lang is 
> 'missing' from the model described in m&s.  m&s is quite clear
> that the language is 'part of' the literal.

Sorry, sloppy terminology on my part.

> There are other approaches [to parseType="Literal"] which we should
> also explicitly consider.

Indeed.

> > Depending on our resolution of the aboutEach issue, we may
> > also need to add a flag to tell if the subject is simple or
> > an aboutEach.
> 
> I'm not convinced of that.  An implementation/api might well have
> that, but that's not what we are designing here, are we?

Right, we are not designing an implementation or API. But
how are those to handle aboutEach if the intended use of the
subject is not flagged? I suppose we could explicitly expand
all the statements.

Ron

Received on Sunday, 15 July 2001 21:51:35 UTC