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 ]

Ok.  Ugly is a data point.  AFs as currently defined 
are ugly when used with attributes.  Namespaces make 
XSLT ugly so we just discovered that the law of the 
preservation of complexity can be renamed to the 
preservation of uglyness.  Call Revlon. :-)

Namespaces at that time were disambiguators (yechh, 
but I have to go fast).  AFs are mapping constructs. 
Namespaces let one build a so-called, compound document, 
but actually, just get rid of naming collisions and 
at the same time, make DOCTYPE somewhat worthless.  Both 
associate a name to an external resource of some t... 
errm.... this always goes south in this part of the 
discussion.  Urrp ugly S meets ugly T and make ugly 

But both are just means of association with respect 
to semantics.  And we don't have a standard means 
of describing semantics.

No matter how we slice this, James is right.  If we 
want to associate semantics/behaviors, something 
more layered has to be at the other end of that 

o   A DTD is pretty good for validation, 
but not co-occurrence constraints.  Neither is Schema 
although schema gets us part way there. Association 
mechanism aside, we'd have to do better than DTDs 
or Schemas as Rick elegantly points out with Schematron.  

o  AFs seem to be a stronger association means, but we 
could possibly have alternative means and still 
be productive.   But what is an "enabling architecture"?

RDDL is an approach based on the namespace mechanism. 
AFs point to "enabling architectures" but I'm 
not sure what those are except it says they are or 
can be DTDs.  I feel like I'm in a self-refential 
loop here.  

Because as Eliot Kimber noted, AFs are "documented" I assume 
they are equivalent to the human-readable parts 
of RDDL.  Yes?  Docs is Docs.  AFs can be inline 
as PIs and that is slightly better than namespaces 
because we don't have to associate via atts that 
invade the content, or get around that with baroque 
rules for inheritance which are system-specific so 
again, invasive.  On the other hand, they work in 
deployed systems. (I feel like Tevye in Fiddler 
On the Roof, suddenly...).

So far, tie game with the exception 
that the namespace uses the URI and therefore 
has a system-specific but widely available means. 
AFs are proven to work but the means isn't widely 
available.  That doesn't mean it can't be; it 
just isn't.  It means AFs need a more compelling 
marketing strategy or a cleaner way to say 
"enabling architecture".  The "enabling architecture" 
is the thing we are after here, yes?  RELAX gives us a 
stronger DTD? That's a good thing, but not the 
whole thing.   Where will the ISO group propose 
for the rest?

How many options can we afford to preserve?  Do 
we need:

1.  Multiple means of associating semantics 
2.  Multiple means of expressing the semantics

Are these the same problem or the difficult 
by multiplicity (too many ways to do the 
same thing in only slightly different 


-----Original Message-----
From: Tim Bray [mailto:tbray@textuality.com]

At 08:57 AM 31/01/02 -0600, Bullard, Claude L (Len) wrote:
>The W3C also has to give up superstitions.  On the 
>other hand, AFs were discussed very seriously and 
>I'm still not sure what the killer objections were. 

In my recollection, the main objection was that the AF syntax 
for namespacing on attributes was seen as really unattractive.  
If we had wanted to do namespaces on just elements, not attributes, 
I'm pretty sure we would have ended up with AFs or equivalent.


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

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