xml-dev - Re: [SML] Whether to support Attribute or not?

[Joe Lapp <jlapp@webmethods.com>]

I understand the problem better after reading other people's responses.
What threw me was the analogy to object data and behavior, which I don't
think is the right analogy.

In each of these example elements

  <lineitem><model>XYZ</model><quantity>3</quantity></lineitem>
  <lineitem quantity="3"><model>XYZ</model></lineitem>
  <lineitem quantity="3">XYZ</lineitem>

'lineitem' has two properties: model and quantity.  It happens that in the
last example the model is not labelled 'model'.  The label is missing,
since strictly speaking XYZ is not the lineitem.

If we throw away the quantity attribute we are left with...

  <lineitem>XYZ</lineitem>

XYZ may indeed represent the line item, but we could have chosen a more
specific word...

  <model>XYZ</model>

I'd argue that if an element has attributes in addition to text content,
then the attributes together with the content define the element, and the
content must therefore be yet one more property of the element.  The
property simply has not been named.

You might consider that a shortcoming of XML.  By allowing attributes it
allows elements to have unnamed properties.  I'm having trouble
interpreting this as an advantage that attributes give.  Were there never
attributes, every property would have a label.  (Unless there is mixed
content, which prompts my next thread...)

I think the solution for SML/XML conversion is give this property an
explicit name.

At 04:21 AM 11/28/1999 -0500, Clark C. Evans wrote:
>On Fri, 26 Nov 1999, Don Park wrote:
>> I believe it is now time to address the question of
>> whether Attribute should be supported in SML or not.
>
>Summary:
>
>  Attributes cannot be eliminated without 
>  providing a suitable replacement.
>
>Discussion:
>
>  The reason why SGML/XML/SML is so powerful is
>  that it accurately reflects the dual nature
>  of reality.  Code has two aspects -- it is 
>  edited as data and run as instructions.
>
>  This pattern is recursive.  Witness yet another

>  compiler ("yacc"), it is code which instructs the 
>  generation of code.  
>
>  XML is powerful beacuse it recognizes that there are 
>  _always_ two simotanenous contexts that must be
>  distinguished:  data and markup.  
>
>  Attributes are the result of applying this same 
>  pattern recursively on the markup itself.   Thus, a 
>  given tag can have instructions (the attribute) and 
>  data for those instructions (the attribute's value).   
>  
>  Attributes therefore, allow a second order approximation
>  to the recursive pattern:
>
>                           [Attribute]
>                        /               
>               [Markup]
>            /           \\ 
>           /               [Value] 
>
>  [Document]                            
>                                    /  [Attribute] 
>           \\              [Markup] 
>            \\           /          \\ [Value]
>               [Content]  
>                        \\
>                           [Content]   ...
>                       
>
>  Unfortunately, as pointed out on this list many, many 
>  times -- by having a different syntax, attributes do
>  not allow for further recursion.  Thus, there is an
>  entire realm of reality which cannot be described 
>  using XML, since attributes cannot have children.
>
>  Thus, I really doubt that it is possible to have
>  a meaningful markup language without attributes --
>  however, finding a recursive replacement would 
>  be very good.
>
>  Consider:   
>    
>    <element att="val"> <content/> </element>
>
>    If attributes were eliminated, this would be mapped to:
>    
>    <element> <att>val</att> <content/> </element>
>
>  
>  Possibility #1:
>
>    Use a hard-coded namespace,
>
>    <element> <attribute:att>val</attribute:att> <content/> </element>
>    
>  Possibility #2:
>   
>    Use a marker,
>
>    <element> <$att>val</$att> <content/> </element>
>
>  Possibility #3:
>
>    Use another type of brackets,
>
>    <element> {att}val{/att} <content/> </element>
>
>  Possibility #4:
>
>    Use a divider,
>
>    <element> <att>val</att> <|> <content/> </element>
>  
>
>  In any case, replacing the attribute mechanism with
>  one that allows for recursion would allow for
>  stuff like:
>
>   <para alt="<b>alt</b>"> para </para>
>
>  To be legally expressed (using syntax #4):
>
>   <para> <alt><b>alt</b></alt> <|> para </para>
>
>
>Hmm.  Thoughts? 
>
>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)
> 
--
Joe Lapp              (Looking for some good people to help design
Senior Engineer        and build the Internet's business-to-business
webMethods, Inc.       XML infrastructure.  We are 100% Java.)
jlapp@webMethods.com           http://www.webMethods.com

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)