OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: RFC: Attributes and XML-RPC

[ Lists Home | Date Index | Thread Index ]
  • From: Marcus Carr <mrc@allette.com.au>
  • To: Tyler Baker <tyler@infinet.com>
  • Date: Wed, 22 Sep 1999 12:09:24 +1000


Tyler Baker wrote:

> I agree. In object to element mappings in an application, I have found it useful to think of
> attributes as arguments passed to the constructor of the object you are creating and the child
> elements of the containing element to be the properties of the containing element.

Yes, I think I consider them along similar lines.

> But approach
> number 2 I think is much more extensible since attributes can ony contain primitive type values
> unless of course the attribute is just used as a pointer to some other element.

I asuume that you meant this example:

<chapter>
   <security>u</security>
   <title>Wheeled Armoured Toys</title>
   <para0>
      <security>u</security>
      <para>WATs are your friend...</para>
         <security>u</security>
   </para0>
</chapter>

I agree that it is very extensible and in many cases would be adequate, but I still feel that it
lacks some of the rigidity that atttributes offer - for example what would the status be of the
processing instruction in the following (incomplete) fragment?

<chapter>
   <security>c</security>
   <title>Wheeled Armoured Toys</title>
   <para0>
      <? You can start that baby without a key... ?>
      <security>u</security>

Would it inherit the "c" classification from the ancestor security element or would "u" be applied
because it exists inside the para0 element? Should the application apply the value to everything
that occurs in the parent element, or does the security element act more like a switch? The same
argument can't be made for the evaluation of processing instructions between elements containing an
attribute, because the processing instruction always occurs inside an element, so it can inherit the
value (or lack thereof) from that element.


--
Regards,

Marcus Carr                      email:  mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS