See also: IRC log
<benadida> issues list
Ralph: do you have a use case for plain literals?
Ben: Jeremy suggested this; he implied it had been done before
<benadida> point 8 in "Comments on RDF/A spec"
-> Plain Literals in RDF Concepts
Ben: this feature allows you to avoid some data duplication
Ralph: do we have a strong requirement for plain literals -- the concatenation example in the issues list?
Jeremy: the goal was to have inline content just once and many RDF Schemas would expect this text to be a plain literal. Plain literals would be more natural to the RDF Community than XML literals
Ben: the idea of concatenating the content of the child elements also appears in Ian Davis' Embeddable RDF proposal
Jeremy: it's appealing to invent a pseudo-datatype in our syntax but it would have special syntactic rules. Special rules would be annoying from an implementation point of view
Ben: it feels to me like a small enough impact on the syntax to be worth the positive result. see 5.1.2.1 in RDF/A syntax
-> 5.1.2.1 Literal from string value of meta
Ben: if 5.1.2.1 stays then we'd have to add a special datatype to make plain literals
Jeremy: the complication of a special datatype is that plain literals are not a datatype. A second complication related to xml:lang. In 5.1.2.1 if there were an xml:lang attribute it would be discarded as typed literals do not have language information. It becomes horrendously complicated in 5.1.2.1 if we add plain literal support and there are multiple xml:lang attributes; we'd likely need to specify that xml:lang must be discarded if there is contradictory data
Ralph: language handling in literals was a very contentious issue for internationalization. We should approach this area with caution
Jeremy: xsd:string does not contain language information. In an XHTML document we have textual data that is natural language data and may be marked up with language information. If in the process of constructing metadata from this -- converting from the presentation format to the RDF format -- we lose language information in a way that is cavalier, I would expect the I18N people to complain. I don't think it is cavalier to discard language information on data that is explicitly typed; e.g. when explicitly datatyped as datatype="xsd:string". If we have a plain literal pseudo-datatype then it would be cavalier to discard language information, so I think plain literals should behave differently from typed literals even though the syntax is similar. XHTML2 is intended to be a means to transport natural language text so it may be more important to preserve language information in XHTML2 literals than in XML literals
Ben: so issue 13 is really just a plain literal issue and I've been generalizing it
Jeremy: the issue list should include discussion of discarding xml:lang
ACTION: Ben update issues list to add discarding of xml:lang information [recorded in http://www.w3.org/2005/11/22-swbp-minutes.html#action01]
Jeremy: xml:lang attributes on child elements that contradict xml:lang on the parent create a problem; we'll have to make an arbitrary choice. Whatever choice we make isn't likely to cause much fuss
Ben: what problems would we introduce if we defined a pseudo-type?
Jeremy: confusion if someone attempted to use that pseudo-type in RDF/XML
Ralph: I'd like to see a use case for this. consider the following RDF/XML and RDF/A examples, which should generate the same value type:
<dc:title><b>This</b> is a book</dc:title>
<meta property="dc:title"><b>This</b> is a book</meta>
Jeremy: in terms of document size, specifying
the pseudo-type will be just as much space as repeating the text
... different argument is that RDF tools should support natural language
information expressed in XHTML2 documents
<benadida> <meta xml:lang="en" property="dc:title"><b>This</b> is a book</meta>
Jeremy: xml:lang attribute on meta would be ignored under current RDF/A syntax spec but an xml:lang on <b> should be preserved. The XML literal is required to be canonicalized via the XML exclusive canonicalization algorithm
Ben: seems to be an oversight if xml:lang on the element containing a property attribute is ignored
Jeremy: not an oversight; there's no place to put this language information. Consider the example in issue 13; the XML literal has 4 children; two element nodes and two text nodes. On the element nodes we can hang language information but we'd have to invent some new node type to hang language on the text. The decision to drop xml:lang information was contentious in the RDF Core WG but the resolution relied on saying that with an RDF/XML document, RDF could specify the handling of xml:lang. This resolution would not carry over to an XHTML document. During RDF Core deliberations I proposed a design in which XML literals had a wrapper node but that design was rejected by the WG
Ralph: yeah, we need to treat XHTML document content with more respect
Jeremy: I prefer the option of adding spans
[Jeremy proposed that option in point 7 of Comments on RDF/A spec]
Jeremy: it would be a bad thing to encourage RDF apps to use just xsd:string. When extracting metadata from XHTML2, we should encourage preservation of language information
Ben: so tentatively we'll say 'no' to issue 13
Ben: I'd like to make this kind of link element clickable. Mark agreed but proposed some additions
Ralph: seems reasonable but I would leave this
to the HTML WG to decide; it feels out of scope for this task force.
I would not want to strongly advocate either way from an RDF perspective;
you're asking for behavior from XHTML2 processors
Ben: do we see any complications?
Ralph: making link act a lot like anchors? I can't see a complication but I've never written a browser
Jeremy: in XHTML2 anchor is more superfluous; it's the presence of href that matters
Ben: if the Task Force does not express an opinon we give up one of our requirements. In the current XHTML2 syntax the example in issue 9 does not make a clickable link. This example is something we might want to express
Ralph: regrets if we meet next week (29 Nov)
Jeremy: I expect to be available on the 29th
Change Log:
$Log: 22-swbp-minutes.html,v $ Revision 1.2 2005/11/23 14:25:38 swick Cleanup for publication