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

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Bruce,

I think there is some basic misunderstanding here. In the XForms 
approach, the RDF triple would be stored in the RDF-XML stream only. The 
XForms binding would only be used to display the RDF triple's object in 
the content. So, an RDF application does not has to care about the 
XForms binding. It finds all information it requires in the RDF-XML. The 
content.xml does not provide any information (regarding that triple) 
that may be of interest for the RDF application. Vice versa, an 
application that just wants to update text fields does not need to know 
anything about RDF. It just can use the XForms binding to get the 
required value.

Furthermore, there may be RDF triples in the content.xml as well, 
contained in text fields. They would not make use of any XForms features 
(but also have no link to the RDF-XML).

So, I really can't see how this would have a negative impact on RDF 
applications, except that there a some restrictions regarding the 
RDF-XML that can be used.

I hope this helps.

Michael


Bruce D'Arcus wrote:
> 
> 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
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS