[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Treebind] Support of RDF

From: Eric van der Vlist
Subject: Re: [Treebind] Support of RDF
Date: Thu, 30 Jun 2005 15:48:37 +0200

Some more thoughts about this features and its influence on the internal
interfaces of TreeBind...

Up to now, TreeBind has been built on top of two basic interfaces : Sink
and Source.

Source couldn't be simpler:

public interface Source extends PipeElement {

         * @return the name
        public Name getName();

         * @return the value
         * @throws Exception
        public Object getValue() throws Exception;

         * Get all the properties of the source.
         * @return An Iterator of NamedObjects
         * @throws Exception
        public Iterator getProperties() throws Exception;


Sink is almost as simple:

public interface Sink extends PipeElement {
         * Sets the name of a Sink instance.
         * <br><b>Must be called before the first call to <code>add</code></b>
         * @param name: name of the binder instance
         * @throws Exception
        public void setName(Name name) throws Exception;
         * Adds a new attribute.
         * @param name
         * @param value
         * @throws Exception
        public void add(Name name, Object value) throws Exception;

         * Set the value of the Sink when it's a leaf node (mixed contents ala
         * XML are not supported at the moment).
         * @param value the value
         * @throws Exception
        public void setValue(Object value) throws Exception;

         * @return the object built by the BindWriter
         * @throws Exception
        public Object getObject() throws Exception;


The idea is that you build trees by giving to each node a name and a
list of named properties.

Names themselves are defined as an interface:

public interface Name {

         * @return the local part of the name.
        public String getLocalName();
         * @return the full name.
        public String getFullName();
         * @return the domain name (can be a namespace URI, 
         * a package name, ...).
        public String getDomainName();


Current implementations of this interface include "JavaClassName" (where
the domain name is the package name), XmlElementName (the domain name is
the namespace URI) and XmlAttributeName (where the namespace URI of the
parent element can play a role).

Up to now, there is some redundancy between the name of the current node
and the name that you give to a node when you add it or the name you get
associated with a node when you iterate over its properties.

Right now, these names are always the same and we could suppress one of

What's happening with RDF is that, given its triple based model, we need
to dissociate the predicate from the object.

If we look back at the basic example:

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="";
        <title>RELAX NG</title>
                <lname>van der Vlist</lname>

and its triples:

rapper: Parsing file book1.rdf
_:genid1 <> 
<> .
_:genid1 <> "RELAX NG" .
_:genid2 <> 
<> .
_:genid2 <> "Eric" .
_:genid2 <> "van der Vlist" .
_:genid1 <> _:genid2 .
rapper: Parsing returned 6 statements

The author (_:genid2) has a "nature" that is
<> but its role in its association
with the book is <>.

What I am proposing to model that without breaking the current
interfaces is to consider that the "name" of the author node is its
nature (<>) while the "name"
associated with it in the list of properties of the "book" node is its
role in the association (<>).

Note: I don't want to use the RDF terms (predicate/object here since
TreeBind is more generic than that).

What would be the impact on the XML binding?

In the XML example:

<?xml version="1.0" encoding="UTF-8"?>
<book xmlns="";>
    <title>RELAX NG</title>
        <lname>van der Vlist</lname>

For the author element, we would continue to consider that both its role
and nature are <>.

The title element is a string and I think that it makes sense to
consider that its role is <> and its
nature is a Java lang string.

Does that make sense?

We could also envision a PSVI based bindings where the role would be
<>. and the nature would be the
datatype associated with this element.

The other question I am asking myself is: should we change the method
names to reflect that? In that case, the name associated with a node
would become its nature and the name associated as a property would
become a role.

What do you think?


Eric van der Vlist  
(ISO) RELAX NG   ISBN:0-596-00421-4
(W3C) XML Schema ISBN:0-596-00252-1

reply via email to

[Prev in Thread] Current Thread [Next in Thread]