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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [SML] Whether to support Attribute or not?

[ Lists Home | Date Index | Thread Index ]
  • From: Sebastien Sahuc <ssahuc@imediation.com>
  • To: "Clark C. Evans" <clark.evans@manhattanproject.com>, Sean McGrath <digitome@iol.ie>
  • Date: Tue, 30 Nov 1999 12:00:46 +0100

> From: Clark C. Evans [mailto:clark.evans@manhattanproject.com]
> I do find a simple binary split to give insight and act
> as a great guide for organizing information:
> 
>    Attributes: 
>  
>      The rules, directives, instructions,
>      which individually mean nothing in the 
>      current context, but taken together give 
>      structure to the element.  In particuar,
>      these act as "instructions" to the 
>      processor which acts on the xml, configuring
>      the processor so that it knows how to 
>      handle the incoming content.  This information
>      is targeted at the target program, not
>      the final consumer.

I Completely agree with this guideline since I expect attribute to add
behaviours to elements. Indeed when you need some action to be
performed on behalf the element like making an element stateful
(ID="...") for further reference (IDREF="..."), or to differenciate
two elements with a -kind of CSS- 'class' atribute instead of
encapsulating these elements into other elements.
On contrary elements act as content.

>    Content: 
> 
>      Those components, which, in the current
>      frame of reference, have individual value 
>      and are seperable from the whole.  In 
>      particualar, these act as "data" to the 
>      processor -- the information to be processed.
>      This inforamation is targeted to the 
>      final consumer.
> 
> Anyway, to me the distinction is all too clear and 
> it is also irritating when people don't seem to see
> it as I do 

Not only irritating but also hazardous, since I agree I don't use that
much attributes, but when I do, it really makes sense to use them, and
removing support to attribute frightens me more than anything.

Seb

> I recognize that my description is far from perfect.



> 
> However, as the methodology has served me well,
> wish to inform others of what I've learned from 
> diligent reading and study of others.
>  
> > [...]
> > >
> > >I'm not saying that this is a direct analogy, however,
> > >there are domains which attributes are very useful
> > >and mixing them with content seems very confusing.  
> > 
> > I agree they can be confusing to the human eye
> > but so too are CALS tables with all the end-tags!
> 
> Yep. I'm not so happy with <element <att>val</att> />
> but this style of syntax does support a binary
> decomposition of the information.   
> 
> How well such a thing would work really depends
> on valid applications... how well it works in 
> the real world.  
>  
> > Attributes are a form of markup minimization.
> > They are more pleasing to the eye in certain
> > situations. Easier to read and all that.
> 
> I tend to use them to support this particular
> decomposition of the problem domain.  So far
> it has proved to give nice rewards in reduced
> complexity.  I'm still an XML "adventurer", so
> we will see how sustaining the success is.
> 
> > >In any case, if SML were to drop attributes, and not
> > >provide at least a non-recursive replacement, then
> > >I think the solutions using the "simpler" standard
> > >would be far more "complicated" than just using XML.
> > >
> > >And, once again, I'm not sure at all about recursive
> > >attributes... I'm just pointing out the possibility
> > >and thinking out loud.  Sorry if this makes you unhappy.
> > >
> > Apologies about the "harrupmph!" of the last posting.
> > Got a bit worked up. No offense intended.
> 
> Same here.  ;)
> 
> Best,
> 
> Clark
> 
> 
> 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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
> unsubscribe 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)
> 

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 unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe 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