Re: [office-metadata] RDF/XML and XPath

[Bruce D'Arcus <bdarcus@gmail.com>]

On Feb 9, 2007, at 11:00 AM, Michael Brauer - Sun Germany - ham02 - 
Hamburg wrote:

> Yes, you are right, XML is important for us. It's because ODF is 
> defined to be a "XML-based file format specification for office 
> applications", and because our TC's charter explicitly says that "it 
> must be friendly to transformations using XSLT or similar XML-based 
> languages or tools".

Yes, I'm aware of that. I have always been concerned about ease-of-XML 
processing.

For the record, I have long said we should include in the specification 
"should" language about recommended best practices for RDF/XML 
serialization, precisely to make it easier to handle with XML tools. 
But that's not the same as introducing what is a non-standard (from the 
RDF perspective) mechanism which *requires* formal constraint.

> So, using RDF via RDF-XML is in general fine for me. But if RDF-XML is 
> difficult to handle by XML application, then I think we should 
> consider to restrict it to a subset that works well in the XML world, 
> instead of requiring that applications implement an RDF model. Since 
> we are not talking about something new but only a subset of RDF-XML, 
> it remains of cause possible to create RDF models, so we actually 
> would combine both worlds.

But if we force use of XPath to do data-display binding (which is what 
you were proposing the other day) then implementing an RDF model (which 
is by far the preferred way to go here in terms of implementation) 
would not work anything but awkwardly. We would force some -- as yet 
unclear and unstated -- mechanism to store XPaths along with triples.

In other words, we would make the proper RDF-based solution more 
awkward, non-standard, and unreliable.

Even so, my proposed solution would work fine with XML tools as well. 
Looking at the display-property attribute is just as simple (in terms 
of, say, XSLT code) as looking for an attribute that denotes an XPath. 
Would you not agree?

> But not only XML applications benefit from restring the RDF-XML, but 
> ODF benefits from that as well, because we can reuse things we have 
> specified already (the XForms bindings) and that have turned out to 
> work well (in the XML world). This helps to keep the specification 
> size small, simplifies ODF implementations, and saves us work when 
> preparing the specification.

I really don't think you realize how complicated a solution what you 
suggested is. What you suggested (requiring XForms) is going to make 
everything -- ODF spec, and implementation code -- more complicated, 
not less.

You're telling us -- if you still think we must use XForms for 
data-display binding -- that we have to specify a constrained syntax, 
and therefore validate it. That will require a fair bit of 
specification text, and a dedicated RNG schema. Granted, I have 
experimented enough to know this is possible, but even so:

a) it will be a lot of work
b) it will break other toolchains (XMP would be invalid, for example)
c) we have to tell implementors how -- if they do the smart thing and 
use an RDF library for the in-memory model -- they would actually link 
a set of triples to some XPaths, and we would require additional code 
and API changes to do that. E.g. no off-the-shelf open source RDF 
library would work in that context.
d) it will not be in any way more effective at the stated goal than the 
simple solution I am proposing

Bruce