Re: New Editors draft of RDFa API spec

On Sep 14, 2010, at 03:51 , Manu Sporny wrote:

> On 09/13/2010 05:17 AM, Ivan Herman wrote:
>> I removed everything from the answer that does not require further
>> comment and where your change are fine with me!
> 
> Replies to your replies on my replies to your comments, below... :)

Same recursively:-)

[snip]

> 
>>> Fixed. I added a conformance section to 4.1. This is fairly late in
>>> the document, but every section up to that point is non-normative
>>> and doesn't must MUST, SHOULD, etc. We can always move the
>>> conformance section to the top of the document if people don't like
>>> how this reads. I also added the Java clause as well as a clause
>>> stating that a best effort should be performed for languages other
>>> than ECMASCript and Java.
>> 
>> Fine with Java for now, but that might be a slightly different
>> discussion on how to handle the RDFa specific API parts and the
>> generic RDF API issue (Sandro's comments). One approach would be to
>> really really emphasize the ECMAScript part only, not to have some
>> sort of a collision course with all the various RDF toolkit
>> implementations out there in Java already (let alone other
>> languages).
> 
> I don't see how this would put us on a collision course? Anybody can
> create an RDF API that isn't conformant to this RDF API... not everyone
> needs to conform to this API. All we're doing is providing guidance for
> people that want to create interoperable APIs, right?
> 
> I probably don't understand what you mean by "collision course".

If there is a standard, then there is a certain pression on vendors to abide to those. Ie, to get the Jena people to change their implementation, and all the Jena users to move to the new one. This has not been the goal of the WG before, so the non-RDFa community may not have paid attention to this work. It may raise lots of eyebrows, at the minimum, to see that coming...

> 
>>>> ---- 2.1. Goals: although there should be a general discussion
>>>> on this, it may be worth emphasizing that not only the API allows
>>>> for non-RDFa parsers to be used, but the interface offers some
>>>> sort of a generic API to RDF...
>>> 
>>> Fixed. I added a sub-section called "A Modular RDF API" to try and 
>>> clarify this a bit more.
>> 
>> Actually... in view of the discussion we had last week on the call,
>> maybe it is better not to have that there for now. It was not an
>> original design goal in the first place, it just happened that way.
>> It definitely was not part of the charter, for example... Sorry to
>> have led you to this!
> 
> It may have not been in the charter, but it was a design goal from the
> very early stages of the document. Even before we started work, we were
> wondering whether or not we'd be able to create an RDFa API before
> having an RDF API. Besides, we're still in the design stages. I
> distinctly remember Benjamin, Mark and I having a conversation about the
> separation between the RDF API and the RDFa API in the very early days
> of the spec - probably around May 2010.
> 
> Now, I think I disagree that we should take it out :). What's the harm
> in keeping it in there?

See above. I see it more as being the result of a natural technical evolution.

[snip]

> 
>>>> ---- 2.2 Concept diagram: I am not sure how, but it might be good
>>>> to have on the diagram and the accompanying text, references to
>>>> some of the 'sections' of the document. We use, for example, the
>>>> term 'RDF Interfaces' in the text; maybe using the same term on
>>>> the diagram would be good (if the diagram is in SVG, it should be
>>>> a clickable link to the relevant section...). Same for the others
>>>> and the text itself.
>>> 
>>> I agree with you in principle - things start to fall apart after
>>> that...
>>> 
>>> I tried SVG without all of the extra non-W3C shim code required to
>>> make SVG work cross-browser. I tried to make native SVG work for 4
>>> hours straight one day... couldn't get it to work across all
>>> browsers - sizing issues. I gave up. The source document is in SVG
>>> if someone would like to give it a shot.
>> 
>> What I did in the past is to use <object> with a fall back to a png
>> version. Didn't that work?
> 
> It wasn't the fallback that was the issue. As you alluded, it was that
> Firefox and Google Chrome use two different SVG rendering engines and
> one of the two was creating black squares in the diagram and performing
> resizing incorrectly. I'm sure it had to do with the output for
> diagramming tool I was using... but it was difficult to debug exactly
> what was going on.

Send me the SVG files. Maybe I can see what is going on. I can also redo the diagram in AI, it seems that the SVG generated by Adobe is more fool-proof (after some manual editing...)

> 
>>> Could you provide a suggestion? It took me 2 hours to come up with
>>> and implement that example for an advanced query :). I don't want
>>> to implement something else unless we have some kind of general
>>> agreement that the example is not esoteric. That and my brain hurts
>>> right now... help? :)
>> 
>> using the 'title' attribute because I want to hire people with a 'Dr'
>> degree? It sounds very similar...
> 
> Seeing that the W3C has this stigma attached to it of containing ivory
> tower academics, we may want to pick an example that is more accessible
> to the general public :). Not to say that my example was any more
> accessible... but since we're talking about it... those external to W3C,
> that don't have PhDs, could view this in a less than favorable light.
> "Oh, so you have to have 'Dr' in your name to not be glossed over for a
> job, eh?!"

You can also set up the example by _excluding_ those with a Dr title from the job:-)

> 
> What about searching for a person's birthday to send them a Happy
> Birthday wish?

That could work, too...

[snip]

Cheers

Ivan

----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf