- From: Frank Manola <fmanola@mitre.org>
- Date: Thu, 24 Jul 2003 11:04:36 -0400
- 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 UTC