Question about union operator (|)

Discussion in 'XML' started by Art Spasky, Aug 30, 2007.

  1. Art Spasky

    Art Spasky Guest

    Hello

    Can somebody help in my question about Xpath?

    When I union node-sets by operator "|" in which order will be nodes :

    - in order they meet in xml document?
    - in order the node-sets evaluates in xpath expresssion?
    - the behaviour is not defined?


    Thank you in advance
     
    Art Spasky, Aug 30, 2007
    #1
    1. Advertising

  2. * Art Spasky wrote in comp.text.xml:
    >Can somebody help in my question about Xpath?
    >
    >When I union node-sets by operator "|" in which order will be nodes :
    >
    >- in order they meet in xml document?
    >- in order the node-sets evaluates in xpath expresssion?
    >- the behaviour is not defined?


    In the XPath data model, node sets are unordered (otherwise you would
    call them sequences of distinct nodes or similar). So none of the above.
    Searching for "order" in http://www.w3.org/TR/xpath might answer what-
    ever question you are really trying to resolve.
    --
    Björn Höhrmann · mailto: · http://bjoern.hoehrmann.de
    Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
    68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
     
    Bjoern Hoehrmann, Aug 30, 2007
    #2
    1. Advertising

  3. In article <>,
    Bjoern Hoehrmann <> wrote:

    >>When I union node-sets by operator "|" in which order will be nodes :
    >>
    >>- in order they meet in xml document?
    >>- in order the node-sets evaluates in xpath expresssion?
    >>- the behaviour is not defined?


    >In the XPath data model, node sets are unordered (otherwise you would
    >call them sequences of distinct nodes or similar). So none of the above.


    However, the operations which appear to work on ordered node sets
    (such as position()) will work as if the set was in document order. So

    ($a|$b)[3]

    will find the third node of the union in document order.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Aug 30, 2007
    #3
  4. Art Spasky

    Pavel Lepin Guest

    Bjoern Hoehrmann <> wrote in
    <>:
    > * Art Spasky wrote in comp.text.xml:
    >>Can somebody help in my question about Xpath?
    >>
    >>When I union node-sets by operator "|" in which order will
    >>be nodes :
    >>
    >>- in order they meet in xml document?
    >>- in order the node-sets evaluates in xpath expresssion?
    >>- the behaviour is not defined?

    >
    > In the XPath data model, node sets are unordered
    > (otherwise you would call them sequences of distinct nodes
    > or similar). So none of the above. Searching for "order"
    > in http://www.w3.org/TR/xpath might answer what- ever
    > question you are really trying to resolve.


    Well, I must admit I'm lost. Doesn't the notion of context
    position define an ordering on any node-set? And if there
    aren't any guarantees about the meaning of context position
    for resulting node-sets, doesn't that mean half the
    transformations/XQueries/XPath expressions in the world are
    going to break the moment a conforming implementation that
    doesn't use the document order as ordering for node-sets it
    produces appears?

    Can perhaps someone clarify what does all of that mean:

    a). That's the way it is, for a good reason I missed.
    b). That's the way it is, for no good reason.
    c). There is some sort of guarantee in XPath spec or
    related documents that I failed to find.

    --
    This chickenus crossed the roadus while yodelingus.
     
    Pavel Lepin, Aug 30, 2007
    #4
  5. In article <fb6a4p$9s4$>, Pavel Lepin <> wrote:

    >Well, I must admit I'm lost. Doesn't the notion of context
    >position define an ordering on any node-set? And if there
    >aren't any guarantees about the meaning of context position
    >for resulting node-sets


    There are. Predicates can be applied in steps, in which case the
    context position comes from the direction of the step's axis, and in
    filter expressions, in which case the direction of the child axis is
    always used (i.e. forwards).

    An expression like ($a|$b)[3] is a filter expression, so the predicate
    "filters the node-set with respect to the child axis" (XPath 1.0
    section 3.3) - that is, it takes the set in document order.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Aug 30, 2007
    #5
  6. Art Spasky

    Art Spasky Guest

    On 30 , 14:40, (Richard Tobin) wrote:
    > In article <fb6a4p$>, Pavel Lepin <> wrote:
    >
    > >Well, I must admit I'm lost. Doesn't the notion of context
    > >position define an ordering on any node-set? And if there
    > >aren't any guarantees about the meaning of context position
    > >for resulting node-sets

    >
    > There are. Predicates can be applied in steps, in which case the
    > context position comes from the direction of the step's axis, and in
    > filter expressions, in which case the direction of the child axis is
    > always used (i.e. forwards).
    >
    > An expression like ($a|$b)[3] is a filter expression, so the predicate
    > "filters the node-set with respect to the child axis" (XPath 1.0
    > section 3.3) - that is, it takes the set in document order.
    >
    > -- Richard
    > --
    > "Consideration shall be given to the need for as many as 32 characters
    > in some alphabets" - X3.4, 1963.


    I understood about predicates. But what about that

    source xslt

    <?xml version='1.0' ?>
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/
    Transform">
    <xsl:template match="/root/a[1]" priority="10">
    <doc>
    <xsl:for-each select="following::*|descendant::*|ancestor::*|
    preceding::*|self::*">
    <res><xsl:value-of select="name(.)"/></res>
    </xsl:for-each>
    </doc>
    </xsl:template>

    </xsl:stylesheet>

    source xml:

    <?xml version="1.0"?>
    <root>
    <a>
    <b></b>>
    <c></c>
    </a>
    <d>
    </d>
    </root>

    in "select" attribute of <xsl:for-each> there is no any predicates,
    but nodes in the node-set formed by xpath expression are in order they
    occur in xml document.
     
    Art Spasky, Aug 30, 2007
    #6
  7. * Art Spasky wrote in comp.text.xml:
    ><xsl:for-each select="following::*|descendant::*|ancestor::*...">


    The expression evaluates to a node set. A node set is an unordered
    collection of distinct nodes. The order in which the nodes are pro-
    cessed is imposed by the semantics of xsl:for-each, not by some in-
    trinsic ordering of the node set. http://www.w3.org/TR/xslt notes:

    The nodes are processed in document order, unless a
    sorting specification is present (see [10 Sorting]).

    The perceived ordering is always external to the node set.
    --
    Björn Höhrmann · mailto: · http://bjoern.hoehrmann.de
    Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
    68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
     
    Bjoern Hoehrmann, Aug 30, 2007
    #7
  8. Art Spasky

    Pavel Lepin Guest

    Richard Tobin <> wrote in
    <fb6aav$bqu$>:
    > In article <fb6a4p$9s4$>, Pavel Lepin
    > <> wrote:
    >
    >>Well, I must admit I'm lost. Doesn't the notion of context
    >>position define an ordering on any node-set? And if there
    >>aren't any guarantees about the meaning of context
    >>position for resulting node-sets

    >
    > There are. Predicates can be applied in steps, in which
    > case the context position comes from the direction of the
    > step's axis, and in filter expressions, in which case the
    > direction of the child axis is always used (i.e.
    > forwards).


    Indeed, the workings of context position in XPath itself
    seem to be well-defined, precisely because either a forward
    or a reverse axis always applies to its evaluation. But
    XPath is often used as a DSL, and evaluating an XPath
    expression yields a node-set, which is, by definition, just
    an unordered collection of nodes (and no axis applies to
    evaluation of context position in this case). That was what
    I was referring to. So, for example, the result of:

    <xsl:for-each select="preceding::*">
    <xsl:copy>
    <xsl:attribute name="pos">
    <xsl:value-of select="position()"/>
    </xsl:attribute>
    </xsl:copy>
    </xsl:for-each>

    ....(or its equivalent in any other language using XPath API)
    is not just a little surprising, but actually seems
    unspecified to me. And that's the question I was asking--is
    this behaviour really unspecified? If it is, is there a
    good reason for that? If not, *where* is it specified?

    So far it looks to me that the spec defines the node-sets as
    unordered, but on the other hand implies (which alone is
    bad enough) that the information about the document order
    of the nodes in a node-set should be retained somehow for
    purposes of determining the context position (and if that
    isn't an ordering, I don't know what is). IANALL, so
    perhaps I'm still missing something.

    --
    This chickenus crossed the roadus while yodelingus.
     
    Pavel Lepin, Aug 30, 2007
    #8
  9. In article <fb6fin$rl4$>, Pavel Lepin <> wrote:

    >Indeed, the workings of context position in XPath itself
    >seem to be well-defined, precisely because either a forward
    >or a reverse axis always applies to its evaluation. But
    >XPath is often used as a DSL, and evaluating an XPath
    >expression yields a node-set, which is, by definition, just
    >an unordered collection of nodes (and no axis applies to
    >evaluation of context position in this case). That was what
    >I was referring to. So, for example, the result of:
    >
    > <xsl:for-each select="preceding::*">
    > <xsl:copy>
    > <xsl:attribute name="pos">
    > <xsl:value-of select="position()"/>
    > </xsl:attribute>
    > </xsl:copy>
    > </xsl:for-each>
    >
    >...(or its equivalent in any other language using XPath API)
    >is not just a little surprising, but actually seems
    >unspecified to me.


    When you embed XPath in other languages, you (the language designer)
    have to specify the context for evaluating XPath expressions. So in
    this case, it's XSLT that has to specify it. XSLT 1.0 (section 4)
    specifies that the context for top-level expressions comes from
    current node list (which is an XSLT, not XPath, concept). For
    xsl:for-each, the current node list is specified to be in document
    order unless <xsl:sort> is used. So in your example, the preceding
    siblings are processed in document order and their position matches
    document order.

    >So far it looks to me that the spec defines the node-sets as
    >unordered, but on the other hand implies (which alone is
    >bad enough) that the information about the document order
    >of the nodes in a node-set should be retained somehow for
    >purposes of determining the context position (and if that
    >isn't an ordering, I don't know what is).


    It's certainly a bit odd. XPath has unordered node sets, but also a
    context that implies an ordering. In some circumstances that context
    follows the node set around (e.g. between successive predicates of a
    step) and in some it doesn't (e.g. when a node set is used in a filter
    expression). When the node set is passed up to XSLT the context is
    lost, and XSLT imposes a new context when it uses the node set in a
    new expression. Another language could choose to preserve the context
    between expressions, but that would require a co-operative XPath
    implementation.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Aug 30, 2007
    #9
  10. Art Spasky

    Art Spasky Guest

    On 30 , 16:09, Pavel Lepin <> wrote:
    > Richard Tobin <> wrote in
    > <fb6aav$>:
    >
    > > In article <fb6a4p$>, Pavel Lepin
    > > <> wrote:

    >
    > >>Well, I must admit I'm lost. Doesn't the notion of context
    > >>position define an ordering on any node-set? And if there
    > >>aren't any guarantees about the meaning of context
    > >>position for resulting node-sets

    >
    > > There are. Predicates can be applied in steps, in which
    > > case the context position comes from the direction of the
    > > step's axis, and in filter expressions, in which case the
    > > direction of the child axis is always used (i.e.
    > > forwards).

    >
    > Indeed, the workings of context position in XPath itself
    > seem to be well-defined, precisely because either a forward
    > or a reverse axis always applies to its evaluation. But
    > XPath is often used as a DSL, and evaluating an XPath
    > expression yields a node-set, which is, by definition, just
    > an unordered collection of nodes (and no axis applies to
    > evaluation of context position in this case). That was what
    > I was referring to. So, for example, the result of:
    >
    > <xsl:for-each select="preceding::*">
    > <xsl:copy>
    > <xsl:attribute name="pos">
    > <xsl:value-of select="position()"/>
    > </xsl:attribute>
    > </xsl:copy>
    > </xsl:for-each>
    >
    > ...(or its equivalent in any other language using XPath API)
    > is not just a little surprising, but actually seems
    > unspecified to me. And that's the question I was asking--is
    > this behaviour really unspecified? If it is, is there a
    > good reason for that? If not, *where* is it specified?
    >
    > So far it looks to me that the spec defines the node-sets as
    > unordered, but on the other hand implies (which alone is
    > bad enough) that the information about the document order
    > of the nodes in a node-set should be retained somehow for
    > purposes of determining the context position (and if that
    > isn't an ordering, I don't know what is). IANALL, so
    > perhaps I'm still missing something.
    >
    > --
    > This chickenus crossed the roadus while yodelingus.


    As I undertood:
    XPath evaluates expressions to unordered node-sets.
    The direction of axis in XPath is significant only when location step
    contains predicates.
    In other cases the order of nodes in a node-set defines by external to
    XPath application (for example XSLT).

    Am I right?
     
    Art Spasky, Aug 30, 2007
    #10
  11. Art Spasky wrote:

    > As I undertood:
    > XPath evaluates expressions to unordered node-sets.
    > The direction of axis in XPath is significant only when location step
    > contains predicates.
    > In other cases the order of nodes in a node-set defines by external to
    > XPath application (for example XSLT).
    >
    > Am I right?
    >


    Not really, the ordering is intrinsic to the Xpath 1 data model, not
    something added by XSLT. there is nothing strange about having sets
    (that is, unordered sequeces) over a data type that is ordered.
    Consider sets of integers for example, {1,2,3} and {1,3,2,1,2}
    are the same set of three items, as sets are unorderd, however integers
    are an ordered type and one can process those items in (say) ascending
    order. Sets of nodes are no different. Node sets are unordered but there
    is an ordering on nodes (irrespective of which set they are in) which
    can be used in some (most) processing.

    XPath/XSLt1 is always careful to distinguish a "node set" fom the
    "current node list" the current node list is an ordered list and is what
    is used to evaluate position() etc. In XPath1 though, the current node
    list is a transient object that can not be returned as a result of an
    expression.

    All of this changes in XPath2 of course which has no node sets.
    (Ordered) sequences replace both "node sets" and "current node lists".
    This is useful for some things (for example you can save the result of
    an xsl:sort as a (sorted) sequence) but the model is a lot less elegant
    than XPath1, rather than the semantics of /, | and other set based
    operators falling out naturally as a result of the set based semantics,
    each of the "set" operators in XPath2 has to (on an operator-by-operator
    basis) specify the sorting and removal of duplicates required to emulate
    set semantics using an ordered sequence.

    David

    --
    http://dpcarlisle.blogspot.com
     
    David Carlisle, Aug 31, 2007
    #11
  12. In article <fba0kl$fdl$1$>,
    David Carlisle <> wrote:

    >> As I undertood:
    >> XPath evaluates expressions to unordered node-sets.
    >> The direction of axis in XPath is significant only when location step
    >> contains predicates.
    >> In other cases the order of nodes in a node-set defines by external to
    >> XPath application (for example XSLT).


    >Not really, the ordering is intrinsic to the Xpath 1 data model, not
    >something added by XSLT.


    I think you're mistaken here. In XPath 1 itself, the only place that
    the ordering is an issue is when a predicate is used, and XPath
    expresses that by saying that predicates filter a node set with
    respect to an axis.

    >XPath/XSLt1 is always careful to distinguish a "node set" fom the
    >"current node list" the current node list is an ordered list and is what
    >is used to evaluate position() etc. In XPath1 though, the current node
    >list is a transient object that can not be returned as a result of an
    >expression.


    XPath 1 doesn't mention current node lists. They are introduced in
    XSLT 1. XPath 1 has only unordered node sets and filtering with
    respect to an axis.

    Of course this is just a matter of exposition: the same XPath 1
    language could be defined in terms of node lists rather than sets; the
    lists generated by a reverse axis could be in reverse document order;
    and filter expressions would have to be defined to put their left
    operand into document order.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Aug 31, 2007
    #12
  13. Richard Tobin wrote:
    > In article <fba0kl$fdl$1$>,
    > David Carlisle <> wrote:
    >
    >>> As I undertood:
    >>> XPath evaluates expressions to unordered node-sets.
    >>> The direction of axis in XPath is significant only when location step
    >>> contains predicates.
    >>> In other cases the order of nodes in a node-set defines by external to
    >>> XPath application (for example XSLT).

    >
    >> Not really, the ordering is intrinsic to the Xpath 1 data model, not
    >> something added by XSLT.

    >
    > I think you're mistaken here. In XPath 1 itself, the only place that
    > the ordering is an issue is when a predicate is used,


    ah but I didn't say it makes a difference, only that it (document order)
    is intrinsic to the xpath data model. It's not added by xslt. I was
    wrong to say xpath uses the term current node list though, that
    terminology isn't used in xpath as you say. (it could have been but the
    effect of position() is described directly without giving a name to the
    "node set in document or reverse document order"

    > and XPath
    > expresses that by saying that predicates filter a node set with
    > respect to an axis.


    yes thanks for the correction.
    >
    >> XPath/XSLt1 is always careful to distinguish a "node set" fom the
    >> "current node list" the current node list is an ordered list and is what
    >> is used to evaluate position() etc. In XPath1 though, the current node
    >> list is a transient object that can not be returned as a result of an
    >> expression.

    >
    > XPath 1 doesn't mention current node lists. They are introduced in
    > XSLT 1. XPath 1 has only unordered node sets and filtering with
    > respect to an axis.


    True, but the point I was trying to make (not that well:) was that
    these are sets over an ordered domain.
    >
    > Of course this is just a matter of exposition: the same XPath 1
    > language could be defined in terms of node lists rather than sets; the
    > lists generated by a reverse axis could be in reverse document order;
    > and filter expressions would have to be defined to put their left
    > operand into document order.
    >
    > -- Richard


    which is closer to the xpath2 way. Not just filter expressions, but also
    / for example need to invoke re-ordering (or removal of duplicates) as
    would |.

    David
    --
    http://dpcarlisle.blogspot.com
     
    David Carlisle, Sep 1, 2007
    #13
  14. In article <fba7ob$n0p$1$>,
    David Carlisle <> wrote:

    >which is closer to the xpath2 way. Not just filter expressions, but also
    >/ for example need to invoke re-ordering (or removal of duplicates) as
    >would |.


    In pure XPath 1, the only way to detect the ordering would be with a
    predicate, and predicates are only used in two places: steps and
    filter expressions. In steps, node lists would retain their order, so
    the only place you would have to re-order them is when evaluating a
    filter expression.

    So in preceding-sibling::*[1] the list would not get re-ordered, but
    in (preceding-sibling::*)[1] it would, and in (a|b)[1] it would not
    have to be re-ordered before the union, but it would probably be much
    more convenient to do so.

    I think the difference between path[1] and (path)[1] is one of the
    most counter-intuitive bits of XPath.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Sep 1, 2007
    #14
  15. Art Spasky

    Art Spasky Guest

    On 1 , 02:30, (Richard Tobin) wrote:
    > In article <fba7ob$n0p$1$>,
    > David Carlisle <> wrote:
    >
    > >which is closer to the xpath2 way. Not just filter expressions, but also
    > >/ for example need to invoke re-ordering (or removal of duplicates) as
    > >would |.

    >
    > In pure XPath 1, the only way to detect the ordering would be with a
    > predicate, and predicates are only used in two places: steps and
    > filter expressions. In steps, node lists would retain their order, so
    > the only place you would have to re-order them is when evaluating a
    > filter expression.
    >
    > So in preceding-sibling::*[1] the list would not get re-ordered, but
    > in (preceding-sibling::*)[1] it would, and in (a|b)[1] it would not
    > have to be re-ordered before the union, but it would probably be much
    > more convenient to do so.
    >
    > I think the difference between path[1] and (path)[1] is one of the
    > most counter-intuitive bits of XPath.
    >
    > -- Richard
    > --
    > "Consideration shall be given to the need for as many as 32 characters
    > in some alphabets" - X3.4, 1963.


    I am sorry, but during this long discussion I have not received ground
    and clear answer for my question

    As I undertood:
    1 XPath evaluates expressions to unordered node-sets.
    2 The direction of axis in XPath is significant only when location
    step
    contains predicates.
    3 In other cases the order of nodes in a node-set defines by external
    to
    XPath application (for example XSLT).

    Am I right?
     
    Art Spasky, Sep 2, 2007
    #15
  16. Art Spasky wrote:
    > 1 XPath evaluates expressions to unordered node-sets.
    > 2 The direction of axis in XPath is significant only when location
    > step
    > contains predicates.
    > 3 In other cases the order of nodes in a node-set defines by external
    > to
    > XPath application (for example XSLT).


    Confirmation: Search the XPath spec for "order" and note where it does
    and doesn't appear.

    I believe XPath's result order was deliberately left somewhat fuzzy in
    order to permit implementation to produce results in whatever order was
    most efficient, which may vary depending on their underlying data model.
    The caller's needs may affect that choice, when known -- if you're
    doing an existence test order doesn't matter, whereas if you're
    processing the nodes in doc order (as is usually the case in XSLT) it
    may be desirable to discover them that way rather than sorting them later.

    By the way, if you're implementing XPath, watch out for the definition
    of //. (I'm still trying to find someone who can explain to me why this
    operation was explicitly defined as a top-down scan rather than as a
    traditional postorder tree walk. Both are perfectly reasonable
    operations, but I would expect the latter to be more commonly used and
    hence a better meaning for the shorthand // operator. And having to
    constantly remind folks that it *isn't* just document-ordered
    descendant:: has been an ongoing nuisance.)



    --
    () ASCII Ribbon Campaign | Joe Kesselman
    /\ Stamp out HTML e-mail! | System architexture and kinetic poetry
     
    Joe Kesselman, Sep 2, 2007
    #16
  17. In article <>,
    Joe Kesselman <> wrote:

    >By the way, if you're implementing XPath, watch out for the definition
    >of //. (I'm still trying to find someone who can explain to me why this
    >operation was explicitly defined as a top-down scan rather than as a
    >traditional postorder tree walk. Both are perfectly reasonable
    >operations, but I would expect the latter to be more commonly used and
    >hence a better meaning for the shorthand // operator. And having to
    >constantly remind folks that it *isn't* just document-ordered
    >descendant:: has been an ongoing nuisance.)


    I'm not sure I understand your description, but if you mean "why is it
    defined as descendant-or-self::node()/ rather than descendant::", it's
    so that expressions like //p[1] mean "all paragraphs that are first
    children" rather than "the first paragraph". I believe this was
    considered more common in formatting, and practical to implement as a
    match pattern (predicates in match patterns can only occur after
    child:: or attribute:: steps, so position() only requires examination
    of siblings, rather than the whole tree).

    -- Richard


    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Sep 2, 2007
    #17
  18. Richard Tobin wrote:
    > I'm not sure I understand your description, but if you mean "why is it
    > defined as descendant-or-self::node()/ rather than descendant::", it's
    > so that expressions like //p[1] mean "all paragraphs that are first
    > children" rather than "the first paragraph".


    I presume you mean "all paragraphs that are the first paragraph".

    I can see where that argument might have been advanced. But all our
    experience with the rest of the XPath expression language leads us to
    expect it to mean the latter. Convenience needs to be balanced against
    principle of least surprise, and I believe the d-or-s::node() expansion
    of // violates that principle.

    If they wanted to provide a shorthand for this purpose, fine, but they
    should also have provided a shorthand for descendant, to help keep the
    two from getting confused.

    Too late to fix now; it is what it is. But I still put it in the
    category of "warts to be fixed someday."

    --
    () ASCII Ribbon Campaign | Joe Kesselman
    /\ Stamp out HTML e-mail! | System architexture and kinetic poetry
     
    Joe Kesselman, Sep 3, 2007
    #18
  19. In article <>,
    Joe Kesselman <> wrote:

    >> I'm not sure I understand your description, but if you mean "why is it
    >> defined as descendant-or-self::node()/ rather than descendant::", it's
    >> so that expressions like //p[1] mean "all paragraphs that are first
    >> children" rather than "the first paragraph".


    >I presume you mean "all paragraphs that are the first paragraph".


    Yes.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Sep 3, 2007
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt Garman
    Replies:
    1
    Views:
    690
    Matt Garman
    Apr 25, 2004
  2. Luca

    union question

    Luca, Aug 27, 2003, in forum: C++
    Replies:
    3
    Views:
    332
    Ron Natalie
    Sep 2, 2003
  3. Paul E Johnson

    union, ternary operator, and C. What a mess!

    Paul E Johnson, Oct 17, 2003, in forum: C Programming
    Replies:
    3
    Views:
    484
    Ed Morton
    Oct 17, 2003
  4. Paul E Johnson
    Replies:
    2
    Views:
    598
    Christian Bau
    Oct 17, 2003
  5. Peter Dunker

    union in struct without union name

    Peter Dunker, Apr 26, 2004, in forum: C Programming
    Replies:
    2
    Views:
    924
    Chris Torek
    Apr 26, 2004
Loading...

Share This Page