> I would find it useful to get a better understanding of the intent of the
> WG, what scope of problems are intended to be solved and how does the
> technical proposal relate to that intent. At present the draft charter is
> aimed at a very wide scope but it's not clear to me that a single language
> or WG can really practically cover all of these.
...
> These have somewhat different constituencies and quite different technical
> requirements. The usage scenarios suggest a desire to cover all three (they
> arguably match up roughly in reverse order to the above list).
...
> Covering all three of these does not feel manageable to me, indeed any two
> may be sufficiently divergent to require an uncomfortably long-lived WG. A
> solution designed for one use may actually prove quite useful elsewhere but
> for a WG it seems to me one wants a quite narrow design centre.
>
> So if that framing makes any sense ... what's the *primary* intended focus
> of the WG?
You correctly observed that the draft is aimed to cover all three.
No, it wont cover them all 100% or maybe even 80%. "60% is good
enough" is what I heard a few times around the workshop. The
pragmatic thought behind this is that the benefits of covering all
three with one language will outweigh the costs of having coverage be
incomplete.
Of course percentages have no real meaning here; the question is what
features will make it and which ones wont. Some people on this list
are arguing that 0% of some important set is covered here. The
imporant thing is for it to be clear which use cases will be met by a
particular charter and which ones will not. The current draft falls
short on that, but the DERI draft clearly covers a different set.
You also observe that this seems like too much work. I'm wondering
what the best way is to estimate that. An actual list of things the
Working Group needs to do, and a guestimate of how much time each bit
will take? What I think makes more sense is to have a charter where
at least of few members of the WG think the whole thing is a few weeks
work, and then the whole process can be slowed down as much as
necessary to polish and check the work, but as time runs out you stop
polishing and just call it done.
I don't think the current draft has that quality, but I'm starting to
picture a two-phase version that does, where at least the stuff in
phase one is something you or I would feel we could hammer out in a
couple of weeks if we didn't need to reach consensus. Then saying the
consensus version takes on the order of a year seems more reasonable.
Do you see a subset of this work that could done in such a timeframe
and would still be useful to some user communities? (I imagine the
answer is: what you have implemented in Jena. :-) Have you done the
mental diff between that and the draft?)
-- sandro