[SML] Whether to support Attribute or not?
Joe Lapp
jlapp at webmethods.com
Sun Nov 28 23:35:14 GMT 1999
This argument doesn't work for me. An XML document contains no behavior,
only data. The XML spec gives you two syntaxes for representing data -- a
short one (attributes) and a long one (element content). Data can be
structured in one syntax but not in the other.
A better argument for providing a replacement is the (unresolved) need to
map to and from XML.
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 at 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 at ic.ac.uk the following message;
>unsubscribe xml-dev
>To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at 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 at webMethods.com http://www.webMethods.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list