RFC: Attributes and XML-RPC

[G. Ken Holman]

At 99/09/27 11:08 -0400, Mark Nutter wrote:
>At 11:09 AM 09/23/99 +1000, Marcus Carr wrote:
>>Mark Nutter wrote:
>>
>> > Whether you evaluate the security level first because it's an attribute or
>> > whether you evaluate it first because it's the first child element, you're
>> > still going to evaluate it before you evaluate the (other) child
>> > elements.  Why/how is it worse to deal with it first as a child element
>> > rather than dealing with it first as an attribute?
>>
>>If you deal with it as an attribute, it's reasonable to believe that the 
>>condition specified by the attribute persists for everything between the 
>>start and end tags of the element, as it was established before the 
>>contents of the element was processed. If you deal with it as the first 
>>child element, there is an ambiguity as to whether the condition should 
>>be applied in the same way as for an attribute, for everything from that 
>>point on or just for all child elements. As you may not be able to relay 
>>the handling that you desire, different applications may be expected to 
>>behave differently.
>
>Well, I think that's a good point, though I wonder whether it might not be 
>easy to handle by a simple convention, e.g. "Within a tag, the security 
>level remains the same until explicitly changed".  But I can guess what 
>you'll say next:  what happens when we want to access the child elements 
>out of order, as in this or that object model?  Could be a problem, unless 
>you specify that the markup has to be parsed sequentially before the 
>elements can be accessed randomly.  Hmmm...

When using XPath (as in XSLT), it is really convenient to find attributes 
of ancestral elements, even if the specific ancestor's element type is unknown.

Consider:

     ancestor::*[@security][1]/@security

... which reads:

     "of the ancestor elements that have a security attribute,
      the first such ancestor's security attribute"

This could be very useful for checking a security attribute applicable at 
any level of the document model.

Having written the above I will admit, though, one could state:

      ancestor::*[security][1]/security[1]

... which reads:

     "of the ancestor elements that have a security child,
      the first such ancestor's first security child"

... so they are both equally complex to specify.  I suppose if I were 
dealing with well-formed instances and didn't have a DTD to validate the 
existence of only a single child security element, I could be assured it 
were well-formed with only a single attached security attribute specification.

Not having implemented XPath, I would guess the performance of finding 
attached attribute nodes would be estimated more easily than estimating the 
search of an indeterminate number of child nodes.

............ Ken

--
G. Ken Holman                    mailto:gkholman at CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Website:  XSL/XML/DSSSL/SGML services, training, libraries, products.
Practical Transformation Using XSLT and XPath      ISBN 1-894049-01-2
Next instructor-led training:  1999-11-08, 1999-11-09, 1999-12-05/06,
                              1999-12-07, 2000-02-27/28, 2000-05-11/12


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)