Cart
[Home] [By Thread] [By Date] [Recent Entries]
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 children. 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 association. 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 circumstances)? len -----Original Message----- From: Tim Bray [mailto:tbray@t...] 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.
|
