Re: SPARQL Variable Binding Results XML Format draft - for review

On Wed, 15 Dec 2004 00:23:10 +1000, Simon Raboczi <raboczi@tucanatech.com> wrote:

<snip/>

> >      ISSUE: Normativeness of the XML schemas. Pick one?
> 
> I don't think the <variables> element defined in section 2.2 of the 
> current document shouldn't use empty XML elements to represent the 
> variables.  The reason this isn't a good idea is that the variable 
> elements no longer have a consistent type throughout the document.  For 
> example, I can't assume that <x/> is always the variable ?x and that I 
> should always expect it to have attributes or element content that 
> represent the RDF node that ?x is bound to.  I have to check the parent 
> element, either <variables/> or <result/> to figure out in which 
> context I should be interpreting <x/>.
> 
> I'm not familiar with RELAXNG, but I'm of the impression that XML 
> Schema supports space-delimited lists of qnames or tokens as a simple 
> type.  I'd suggest that something like
> 
> <results variables="x y z">
>    <result>
>      <x>foo</x>
>      <y>bar</y>
>    </result>
>    <result>
>      <x>baz</x>
>      <z>quux</z>
>    </result>
> </results>
> 
> would give every element a consistent type.  

The problem with that is that the attribute value "x y z" cannot be
easily handled by XSLT1 (by far the most common) as it does not have
built-in handling for attribute values that are lists of XML names.
So this has to be done as character-by-character parsing or extension
functions which is just too troublesome.  So, that goes back to the
format I have now:
  <variables>
    <x/>
    <y/>
    <z/>
  </variables>

or an alternative, which would address your concern about the
declaration (if that's the word) of variable name elements being in
the same format/XML type as the use of the elements.

  <variables>
    <variable name="x"/>
    <variable name="y"/>
    <variable name="z"/>
  </variables>

Which is somewhat similar verbosity to what we have now.

I *suppose* you could have
 <variables x="" y="" z="">
and use the attribute names which are easy to access from XML.
However, what would the attribute values be? Ignored?
And it just seems a little crazy and too close to RDF/XML :)

> ... Do we need the outermost <dawg-result> element?

Not if you could squeeze everything into attributes of the document
element, but I doubt that's possible given the caveats above.

It might be that we could record other optional information in a
header such as whether distinct was operating, or if known, the
results size.

Dave

Received on Wednesday, 15 December 2004 12:13:38 UTC