- From: <bugzilla@jessica.w3.org>
- Date: Mon, 03 Jan 2011 18:13:36 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11444
Paul J. Lucas <paul@lucasmail.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |
--- Comment #3 from Paul J. Lucas <paul@lucasmail.org> 2011-01-03 18:13:35 UTC ---
Since I didn't get a response on how, exactly, "there is enough flexibility in
the spec to accomplish what [I] want," I'm re-opening the bug.
To me, the spec as currently written is quite clear in that "the default is to
query all levels *ALL* levels in hierarchical relationships" [emphasis, mine].
Of course the spec doesn't specify what a "level" is either. Although the spec
doesn't explicitly specify that a "level" is implementation-defined, its
silence on that point makes it de-facto implementation-defined. I'm OK with
this, although the spec could say so explicitly. However, I don't feel
strongly enough on that point to file a separate bug.
But whatever an implementation defines a "level" to be, it shouldn't be forced
to query *ALL* of them by default. In addition to the likely semantically
useless results I gave an example of already ("entity" is a synonym of
"canary"), querying *ALL* levels would be more computationally expensive and
hence shouldn't be the default for that reason also.
In practice, hierarchical relationships wouldn't be longer that a dozen or so
levels anyway (but this doesn't negate either of my reasons above for not
querying all of them by default). If a user really wants *ALL* levels, s/he
can specify an arbitrarily high range of, say, "at most 100 levels" and get the
same effect.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 3 January 2011 18:13:38 UTC