RFC: Attributes and XML-RPC

[Mark Nutter]

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...

Ok, but now how about this:  You're doing contract work for the government, 
and all of your documentation uses an attribute to indicate security level, 
e.g. <para security="ts"> for paragraphs classified as Top Secret.  All is 
well, and you have an entire application written that uses Processing 
Instructions that rely on having the security level defined by an attribute 
in the containing tag.  Now the government decides that "ts" (Top Secret) 
is no longer fine-grained enough -- there are a whole new set of "top 
secret" classifications: "ts-ce" (top secret, counter-espionage), ts-snp 
(top secret, security at nuclear power plants), ts-ch (top secret, computer 
"hacking"), and so on, and your paragraphs need to be tagged with all the 
security levels that apply.  You are working on a document that discusses 
security measures used to prevent foreign governments from hacking into 
computers at nuclear power plants.  What now?

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-

Mark Nutter, <mnutter at fore.com>
Internet Applications Developer
FORE Systems
Some people are atheists 'til the day they die.


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)