Re: Primer multiple syntaxes (process + gui coordination)

On Aug 19, 2008, at 11:14 PM, Sandro Hawke wrote:

> While I agree with the essense of your message, I wanted to comment on
> one thing which might be misleading...
>
>> There's no WG decision on which syntaxes to include and probably
>> won't be as I consider it editorial.
>
> I'd say this differently.  I'd say there hasn't been a WG decision  
> on it
> because the WG hasn't felt any need to make a decision on it.

Yes.

> The WG
> can control every byte of every document if it wants to ("editorial"
> doesn't mean the WG doesn't get to decide), but of course things work
> best when the editor can come up with something that's good-enough for
> everyone in the WG.

Yep.

> Hopefully editors can sense when there isn't
> consensus and ask for a WG decision to guide them, but if they end up
> diverging from some members of the WG, and don't notice, then those
> members can point it out and iron the matter out.

Yep. And that's the other aspect of my point: the syntaxes and what  
are default and even the GUI hasn't been settled yet and *nothing*  
was intended to be signaled by the current line up. They are just  
there in order to demonstrate the *approach*. I am, personally, and  
inclusionist wrt syntaxes and I have always considered including  
Turtle *essential*.

For me, there are two reasons to include a syntax: 1) Will that  
syntax be the most comfortable primary reading syntax for some  
reasonable audience. (Clearly, manchester syntax and turtle are no  
brainers on this criterion. Manchester syntax is probably the most  
popular IDE syntax and Turtle is a popular authoring and display  
mechanism for RDF. I myself prefer it for reading RDF. Heck, I  
*contributed* to it and certain gave huge early encouragement to Dave  
to write up the spec.) 2) Will that syntax be helpful to readers as a  
contrast. So, having both turtle and RDF/XML is a *good thing*  
because it's not *always* immediately obvious how the translation  
goes. Similarly, if people want to get comfortable reading the other  
specs, having functional syntax next to their "most comfortable"  
syntax is *really* helpful.

> (Procedurally, they can object to publication until it's fixed.  In
> practice, it's better for everyone to simply point out the divergence,
> and if it's not a trivial matter, open an issue on it.  Whether one
> *should* do all this depends on whether the divergence is such a big
> problem that it's worth the delay that will be incurred.)

Yes. I only meant that the *lack* of a WG decision on anything in the  
primer (other than to publish a WD) thus far shouldn't be read as  
something having been *missing* in the process, i.e., that in the  
*normal* course of the group we'd *have* to fire up a decision on  
this (the way we'd *have* to fire up a decision on publishing a note  
or including a feature).

>> Obviously, this many can only work if they don't overwhelm the UI (in
>> which cases choices will have to be made), but I'm pretty confident
>> that it won't, done right.
>
> Where are we on the UI?  I did some hacking, then went on vacation and
> Peter did some hacking.  I think we agreed on a UI where before the
> first use, there would be an explanation and a global controller; then
> at each use, there would be a collapsed local controller.

I think this remains the basic design. As I'm experimenting with  
other things to hide, I'm considering having a "configuration panel"  
as well as an appendix.

> By having
> controllers always above any text they control, we avoid the  
> problem my
> version had of jumping around.

I wish the current controller would "snap" to the next example rather  
than hovering over the non example text.

Cheers,
Bijan.

Received on Wednesday, 20 August 2008 06:21:46 UTC