Re: RDFa DOM API - New Editor's Draft

Hi Ivan,

> [snip]
>
>>
>> "Parsing" is the job of the "Parser", not the store. To put this in
>> another context. We don't expect a MySQL's InnoDB store to be able to
>> extract information from a non-SQL source and place it into storage.
>
> I am not sure that comparison is relevant, frankly. What we are talking about here is a
> data store that parses in RDF data (ie, using one single data model) that has different
> (ie, conceptually equivalent) serializations. Microdata might be a bit of a stretch at first
> glance, but not that much.

I think what we're dealing with here is actually pretty basic OO
architecture design.

What we're talking about are *interfaces*. If we say that the Parser
interface has a parser() method, and the Store interface has an add()
method (for example), there is still nothing to stop an implementation
from putting both of these *interfaces* onto the same object:

  document.data.parse();
  document.data.add();

That's a convenience for authors, and whether one or more interfaces
are combined onto the same object will depend on the environment in
which the interfaces are being used.

For example, although the granularity of our interfaces allow us
create parsers of different types:

  var parser = xyz.createParser( "rdfa 1.1" );

  parser.parse( ... );

that doesn't mean that an implementation is prevented from creating an
RDFa parser on initialisation, and making its methods available via
some common object:

  document.data.parse( ... );

But the key thing is that it doesn't gain us anything when it comes to
*language design* to merge all of these things together onto one great
big interface definition, for two reasons:

The first is that it confuses issues; it's difficult to talk about
'just' parsing, when someone else wants to talk about the store...it's
difficult to talk about querying when someone else wants to talk about
different parse types. Keeping interfaces separate allows us to talk
about them separately.

The second reason is probably more important; the moment some other
language designer (perhaps from an SVG or Microformats background)
wants to do something slightly different to what is available on our
'monolithic interface', they will have to go and create their own
architecture, and immediately cause fragmentation.


>> That is the job of the application - to "parse" and direct the
>> information into a "store".
>>
>
> I was never particularly bothered by RDFLib's approach to have a parse method on a graph
> or, equivalently, Jena's approach doing the same:
>
> Model model=new ModelMem()
> model.read(new InputStreamReader(in)
>
> Ie, I am not convinced by this argument.

With respect, that may be...but luckily someone was bothered by this!
And as a consequence the parser can take documents from all sorts of
places and extract the data -- that's pretty crucial.

There's nothing to stop anyone combining the RDFLib or Jena interfaces
in a different way to produce another layer for specific environments.
But it's pretty important that underlying these specific
implementations is a common set of interfaces.


> My concern, as always in this thread, is simplicity
> and an attempt to reduce the number of different interfaces...

You keep talking about simplicity Ivan, as if no-one else has the same concern.

I think that's a little unfair, since the whole purpose of RDFa from
its inception was simplicity, the recent push towards profiles (in
RDFa 1.1) was all about simplicity, and the taking of the DOM API in a
new direction in the last few weeks was very much about simplicity.

However, as I've been trying to stress since the beginning of the API
discussion, you can only achieve simplicity once you've worked out the
gory details that make up the architecture, and arranged them into a
coherent whole -- and I think that's the process we're going through.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Monday, 31 May 2010 19:39:07 UTC