W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > July 2003

Re: first pass parseType="Literal" text for primer

From: Frank Manola <fmanola@mitre.org>
Date: Thu, 24 Jul 2003 11:04:36 -0400
Message-ID: <3F1FF584.4000908@mitre.org>
To: Brian McBride <bwm@hplb.hpl.hp.com>
CC: rdf core <w3c-rdfcore-wg@w3.org>, Martin Duerst <duerst@w3.org>, i18n <w3c-i18n-ig@w3.org>

Brian McBride wrote:

> On Wed, 2003-07-23 at 15:26, Frank Manola wrote:
> 
>>Brian--
>>
>>I have both some editorial comments and some technical comments about this.
>>
>>Editorial comments:
>>
>>Putting this as a section 4.5 seems OK.
>>
> 
> I'm happy for you to suggest somewhere better, but this looked ok to me.


No alternative needed, it's fine there.


> 
> 
>>  This will have us covering 
>>parseType="Literal" in 4.5, and we already cover parsetype="Collection" 
>>in 4.2.  As I've already mentioned, we probably in that case should 
>>cover parseType="Resource" too, but this can easily be added to 4.4 (and 
>>there's already an example there that uses it, so all I have to do is 
>>point out what it does).  All I need to do then is add a forward 
>>reference from the typed literal section (2.4) and a brief mention to 
>>these types of "other facilities" at the beginning of Section 4.
>>
> 
> The primer doesn't have to cover everything.  I think we need stability
> more than text on parseType="Resource".


Well, it doesn't have to cover everything, but there's already an 
example of parseType="Resource" in the Primer (in the rdf:value section 
4.4), it just isn't explicitly discussed at all.  And, having added a 
discussion of parseType="Literal", I think it would look funny to 
explicitly talk about two of the three (current) values of the 
rdf:parsetype attribute, and not the third one.  Anyway, I've already 
written the description to go into Section 4.4, and it's only three 
additional sentences.


> 
> 
>>I think we're going to have to explain a bit further what the "need for 
>>care" is at the bottom of the example.  It might not jump out at someone 
>>right away.  Also, I wonder about calling this stuff "rich text";  it 
>>might remind people of rtf, and that's not what we're talking about.
>>
> 
> Ok - dropped rich text.  Added more words about care.


One instance of "rich text" remains, but it's easy to take out.


> 
> 
>>I also think we need to say something explicitly about xml:lang.  A 
>>couple of examples use it already (even before we introduce this new 
>>one), but since one of the issues surrounding this material has been 
>>xml:lang, we probably should say something about it.
>>
> 
> The text does.  Its used in the example and there is specific mention of
> not inheritting it from its context.


Ok, good.


> 
>>Technical comments:
>>
>>1.  Your example uses HTML, but according to the definition of 
>>XMLLiteral, the value is supposed to be XML. 
>>
> 
> Looks like XML to me.


Yes, but the original text *said* it was HTML.  Anyway, your new text 
fixes this.


> 
> 
>> We could say XHTML instead 
>>of XML, but I think we also need to say something explicitly about 
>>handling HTML (and any other non-XML stuff that looks like markup). 
>>People might think they can put any old markup in there, and get a surprise.
>>
> 
> I'm inclinded not to make this too complicated.  I suggest it makes the
> point we need to make and that is sufficient.
> 


Since the text no longer mentions HTML, I agree we don't have to deal 
with this.


> 
>>2.  What happens if someone, instead of using parsetype="Literal", 
>>writes an element with markup content as a regular typed literal with an 
>>rdf:datatype attribute value of rdf:XMLLiteral?
>>
> 
> That is a corner case I don't expect to cover in the primer.


Hmmm.


> 
> 
>>  I would assume this is 
>>supposed to work the same way as writing parsetype="Literal", and the 
>>element content needs to obey the same rules, but we don't explicitly 
>>say anything about it (either saying it's allowed, and it works the same 
>>way, or explicitly forbidding it).  Syntax doesn't seem to explicitly 
>>cover this case either.
>>
> 
> New text follows shortly.
> 
> Brian
> 


Cool.

--Frank




-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875
Received on Thursday, 24 July 2003 10:40:38 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:58:48 EDT