Re: [xsl] Does the count() function require access to the whole subtree?
2014-01-14 16:44:40
In a tree, two branches that overlap are also "nested," or whatever the
more precise term is that we are grasping for, so we can use the terms
interchangeably (in the context of a tree) without any loss of
denotational scope. There's no need for a more precise, yet confusing
for other reasons, word.
If we lived on a planet where the only animals were human, we wouldn't
need a word for humans, as long as we confined ourselves to speak about
animals of our planet, even if we could understand the concept that
there might be other kinds of animals on some other planet.
By the way, in other languages, are there words for "second cousin twice
removed"? English has a terrible way of referring to such familial
relations as my grandmother's great-grandson (who is not my son or my
sibling's). Perhaps in that language there is a word for co-ancestry or
something. IE two people who are related by a direct line of ancestry
(rather than related by marriage or on a different branch).
-Mike
On 01/14/2014 03:34 PM, Dimitre Novatchev wrote:
Well, to call something that is "nested" -- "overlapping" is probably
less precise as calling a human -- "animal" -- because a human is a
true subclass of Animal, while two overlapping concepts aren't
generally in a true containment relationship.
On Tue, Jan 14, 2014 at 12:23 PM, Michael Sokolov
<msokolov(_at_)safaribooksonline(_dot_)com> wrote:
I know what it is that's trying to be expressed (although thank you for the
lovely diagrams), but I disagree about the meaning of "overlap" - it is not
nearly so precise as we might think it is, and certainly encompasses this
situation. In various dictionaries you will see definitions such as "To
have one or more elements in common." Another thought is: "coincident," but
I prefer overlapping.
-Mike
On 01/14/2014 03:11 PM, Dimitre Novatchev wrote:
one vote for overlap. It seems the most obvious and (to me) unconfusing
choice.
Only people whose brains have been contaminated with *other markup
paradigms*
will be confused, and those have nothing to do with XML, do they :)
My brain is not contaminated -- at least not with "other markup
paradigms".
Overlapping means this:
-----------------------------------
---------------|--------------- |
| | | |
| | | |
---------------|--------------- |
-----------------------------------
But what "overlapping" is currently being used to label is this --
this is called "nested"
--------------------------------------
| --------------- |
| | | |
| | | |
| --------------- |
--------------------------------------
Not only I find this very confusing.
On Tue, Jan 14, 2014 at 12:01 PM, Michael Sokolov
<msokolov(_at_)safaribooksonline(_dot_)com> wrote:
one vote for overlap. It seems the most obvious and (to me) unconfusing
choice. Only people whose brains have been contaminated with *other
markup
paradigms* will be confused, and those have nothing to do with XML, do
they
:)
-Mike
On 01/14/2014 11:44 AM, Dimitre Novatchev wrote:
What is wrong with "containment"?
What about "joined" and "disjoint"?
The other precise but not so short names are "directly-related" vs.
"non-directly related", or maybe "strongly-related".
Also: "disparate" vs. "contained"
On Tue, Jan 14, 2014 at 7:24 AM, Wendell Piez
<wapiez(_at_)wendellpiez(_dot_)com>
wrote:
Hi,
On Tue, Jan 14, 2014 at 9:50 AM, Dimitre Novatchev
<dnovatchev(_at_)gmail(_dot_)com>
wrote:
On Tue, Jan 14, 2014 at 4:26 AM, Michael Kay <mike(_at_)saxonica(_dot_)com>
wrote:
I mean that within the set of nodes selected by //x, there may be two
nodes A and B such that A is an ancestor of B.
(I'm not using the term overlap in the sense of non-hierarchic
markup:
perhaps that's the cause of any confusion).
Yes that is a big source of confusion. "Overlap" in its general sense
means that their isn't proper containment -- just intersection.
And this is not the case here at all.
It would be precise and clear to replace the term "overlapping" with
something like "containment".
Yes, this is hard because English appears not to have a verb that
indicates a reciprocal ancestor/descendant relation. Ancestor nodes
may contain, include or "dominate" descendant nodes, but since the
graph is acyclic, nodes never contain each other.
One could say more simply "a 'crawling' expression -- one that selects
both ancestors and their descendants together". But that doesn't solve
the problem for the spec, as in "For example, an implementation might
be able to treat the expression .//title as striding rather than
crawling if it can establish from knowledge of the schema that two
title elements will never overlap" [18.1.1]. I suppose that could be
rewritten too ... "no title element will contain another". Or "will
never coincide".
Does the spec need a term to indicate this relation in the general
case? I agree that the term "overlap" is fraught with other senses,
and should probably be avoided.
Cheers, Wendell
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [xsl] Does the count() function require access to the whole subtree?, (continued)
- Re: [xsl] Does the count() function require access to the whole subtree?, Michael Kay
- Re: [xsl] Does the count() function require access to the whole subtree?, Dimitre Novatchev
- Re: [xsl] Does the count() function require access to the whole subtree?, Wendell Piez
- Re: [xsl] Does the count() function require access to the whole subtree?, Michael Kay
- Re: [xsl] Does the count() function require access to the whole subtree?, Dimitre Novatchev
- Re: [xsl] Does the count() function require access to the whole subtree?, Michael Sokolov
- Re: [xsl] Does the count() function require access to the whole subtree?, Dimitre Novatchev
- Re: [xsl] Does the count() function require access to the whole subtree?, Michael Sokolov
- Re: [xsl] Does the count() function require access to the whole subtree?, Dimitre Novatchev
- Re: [xsl] Does the count() function require access to the whole subtree?,
Michael Sokolov <=
- Re: [xsl] Does the count() function require access to the whole subtree?, Dimitre Novatchev
- Re: [xsl] Does the count() function require access to the whole subtree?, Wolfgang Laun
- Re: [xsl] Does the count() function require access to the whole subtree?, davep
- Re: [xsl] Does the count() function require access to the whole subtree?, Graydon
- Re: [xsl] Does the count() function require access to the whole subtree?, Michael Kay
- Re: [xsl] Does the count() function require access to the whole subtree?, davep
- Re: [xsl] Does the count() function require access to the whole subtree?, Dimitre Novatchev
- Re: [xsl] Does the count() function require access to the whole subtree?, Wendell Piez
- Re: [xsl] Does the count() function require access to the whole subtree?, Michael Sokolov
RE: [xsl] Does the count() function require access to the whole subtree?, Costello, Roger L.
|
|
|