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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Co-operating with Architectural Forms

[ Lists Home | Date Index | Thread Index ]

Lars Marius Garshol <larsga@garshol.priv.no> writes:

> | To this day, nobody has explained what's so unattractive about the
> | AF paradigm, or the precise nature of the esthetics that found the
> | AF solution "ugly".

> The way schema information is piggy-backed into the
> existing schema language in a way that makes it
> appear in the instance data rather than in the schema
> itself is ugly to me.

AFs can work either way.  

AFs can work if you don't have a DTD, which can be
quite important in XML-land.  Of course, in that case,
you have to provide the AF information in each
element's attributes.  If there's no schema, there's no
other way, is there?  XML Namespaces do exactly the
same thing.

AFs can work more elegantly, of course, if you *do*
have a DTD; in that case, you just use #FIXED
attributes.  This method can keep the AF information
completely invisible in the document instances.

So what's the problem?

> Also very ugly is the way many attribute values end
> up being structured in ways that should rather be
> structured with markup.

Are you saying that AFs are ugly because neither SGML
nor XML provides a way to structure attribute values,
and that AFs were designed to live within that
limitation?  It seems unreasonable to complain that the
ugliness of AFs is due to the fact that they're
designed to actually WORK, even though they have
nothing to work with but the SGML and XML markup
languages.

-- Steve

Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA





 

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

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