- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 12 Mar 2008 09:17:04 -0400
- To: public-rif-wg@w3.org
There's an odd complication in the XML syntax, which I want to point out and would like to see addressed at some point. The current BLD gives us bits of XML like this: <Uniterm> <op>predfunc</op> <slot>key1 filler1</slot> . . . <slot>keyn fillern</slot> </Uniterm> and <Frame> <object>inst</object> <slot>key1 filler1</slot> . . . <slot>keyn fillern</slot> </Frame> These are not fully striped. What class of object is contained in the <slot> element? It's some kind of implicit pair or array. To some extent, this complicates implementation, and leaves the object model underspecified. It's not a huge complication if these are the only two, but still, it's something that every parser and serializer and some fallback transforms will have to special-case. == Solution 1 : Stop Being Fully-Striped == It would clean up the syntax in some ways. We could change positional uniterms from : <Uniterm> <op>predfunc</op> <arg>argument1</arg> . . . <arg> argumentn</arg> </Uniterm> to <PositionalUniterm> predfunc argument1 . . . argumentn </PositionalUniterm> Maybe someone should propose an XML syntax for RIF designed for human readability, if we're going down that road. If so, the Presentation-XML-Syntax mapping table will really need the 3rd object-model/RDF column. (Maybe it needs it now.) == Solution 2 : Don't have "slots" be entities or relationships == (Similar to what Christian has in PRD) <Frame> <object>inst</object> <key>key1</key> ... <key>keyn</key> <value>filler1</value> ... <value>fillern</value> </Frame> They might also be interleaved, but that's harder to handle with schema. In either case, schema can't enforce the pairing, but it's pretty obvious if you say each key corresponds to a filler in the same position in the sequence. == Solution 3 == Make slots explicit and fully-striped: <Frame> <object>inst</object> <slot> <Pair> <key>key1</key> <value>filler1</value> </Pair> </slot> . . . </Frame> Tedious, but straightforward/obvious. ================================================================ -- Sandro
Received on Wednesday, 12 March 2008 13:18:29 UTC