Lists Home |
Date Index |
- From: Marc.McDonald@Design-Intelligence.com
- To: firstname.lastname@example.org, email@example.com
- Date: Fri, 20 Aug 1999 15:52:19 -0700
I would say the key advantage of attributes over elements is that attributes
can have defaults. I can define a set of elements to be optional and allowed
in any order by using (Attr1 | Attr2 ...)*. With schemas, I can type the
content of an element. Default values seem the only missing capability.
Marc B. McDonald
Principal Software Scientist
Design Intelligence, Inc.
1111 Third Avenue, Suite 1500
Seattle, WA 98101
> From: Paul Prescod[SMTP:firstname.lastname@example.org]
> Sent: Friday, August 20, 1999 8:56 AM
> To: email@example.com; firstname.lastname@example.org; xml-dev
> Subject: Attr+: Integrating attributes and elements
> This proposal goes one step beyond the one in "&-compromise". It goes a
> step farther towards making XML behave as a property/value language like
> most "OO" languages.
> One of the hardest questions to answer about XML DTD design is:
> "element or attribute." Attributes have certain virtues relating to
> lexical typing and convenience and elements have the primary virtue of
> being able to contain sub-structure.
> XML schemas are set to reduce some of the benefits of attributes but not
> all. Attributes will continue to be more convenient because they can
> come in any order and because they are easier to type.
> The problem is: if you choose to represent something as an attribute,
> for user convenience and "intuitiveness," you can never change your mind
> and allow it to have substructure later.
> I propose a new concept called a "structured attribute" (attr+). An
> attr+ is a property of an element. In most respects it is just like an
> attribute. In fact, not much in the schema spec would change at all.
> Am attr+ is different in that it can be syntactically fulfilled in a
> document by EITHER an XML 1.0 attribute OR a sub-element element of the
> same name. All such elements must precede the "real content" of an
> element. All characteristics must have names that are different from any
> element type name allowable in the element. A processor knows it has
> shifted from processing characteristics to processing "content elements"
> merely by looking at the generic identifiers ("tag names", for
> Let me be clear that there is no new syntax in the document instance. A
> characteristic "foo" of type "IDREF" on element "bar" can be expressed
> <bar foo="abc">...</bar>
> Attr+es can have full content models. If a particular instance of a
> characteristic on a particular element happens to be all text (no
> sub-elements) then it can be expressed as an attribute instead of as an
> element. Over time, the word "attribute" would come to be synonymous
> with the term "characteristic in the minimized syntax."
> The working group can decide whether to keep the concept of "classic
> attribute" alive in the schema -- perhaps for backwards compatibility. A
> classic attribute would be an Attr+ that is constrained to only the
> minimized syntax. You could have an attribute called "StringOnly" or
> something. This would be useful for backwards compatibility. Attr+es
> would give these attributes "a future" in that they could become
> structured later.
> The information set contribution of an attr+ would be an information set
> item just like an Attribute information item except that its value would
> be an arbitrarily sub-strucured node list instead of just references and
> characters as it is now. An extra property would specify whether the
> attribute+ was expressed syntactially as an element or as "classic
> Practically speaking, this means that the XPath @foo could return a node
> with elements as its children. Thanks to the XPath concept of "value",
> this is 100% backwards compatible. Given
> <foo>abc<emph>def</emph>ghi</foo>, @foo would return "abcdefghi" in any
> context expecting a string and the structured content anywhere else.
> It is debatable whether attr+es would show up in the information set as
> element content (or in the child:: axis of XPath). Having them NOT show
> up is probably more convenient because why would they be in two axes? On
> the other hand, this means that schema-using processors would see a very
> different information set than XML 1.0 processors. That may or may not
> be a "big deal." It depends on how much the information set is otherwise
> modified by XMLSchema (archetypes, datatypes etc.).
> There are various ways of making the information set backwards
> compatible and yet making it easy to filter "true content" from
> "attribute content."
> Paul Prescod
> xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
> CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:firstname.lastname@example.org the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:email@example.com the following
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)