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: Joe Lapp <jlapp@webmethods.com>
  • To: xml-dev@ic.ac.uk
  • Date: Sat, 27 Nov 1999 23:48:28 -0500

At 02:41 PM 11/27/1999 +0800, Rick Jelliffe wrote:
>From: Don Park <donpark@docuverse.com> 
>>I believe it is now time to address the question of
>>whether Attribute should be supported in SML or not.
>[...]
>Are you talking about syntax or labelling here?  [...]

Both.  If I ask an element for its date, and there is both an attribute named 'date' and an element type named 'date', I have to know to which I'm referring.  If you mean the element type, then regardless of whether an attribute by that name exists, if no element of that name exists you get nothing.

It's unfortunate that attribute and element names belong to different namespaces.  I wish attributes were merely a syntactic shorthand for giving the values of unstructured elements.  Because they belong to different namespaces, and because they have different canonicalization rules, this cannot be so.

The issue is naming.  The syntactic role of the item necessarily becomes part of the name, since it identifies the missing namespace constituent.

When something external to the document must identify a constituent of the document, it must also indicate whether it refers to the attribute or the element of the given name.  Even the XML namespaces spec gives attributes and elements distinct virtual namespaces within the same XML namespace.

Moreover, if you go from raw data to XML, you have to identify the syntactic role of that data.  Why should we have to carry XML syntax information along with our data?  Absent those syntactic clues, you'll find yourself either shoving all data into element content or shoving all unstructured data into attributes and all structured data into element content.

As before, the issue is complexity.  Every XML application is forced to effectively work with two namespaces for every element: one for the attributes of that element, and one for the child elements.  It's not even possible to partition solutions into a non-namespace aware infrastructure and a namespace-aware superstructure.  It goes to the bone.  The XML namespaces spec formalizes this with its distinction between per-element namespaces and the default namespace; the XML namespaces spec did not introduce these namespaces.
--
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)






 

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

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