Layers, again (was Re: fixing (just) namespaces and validation)
David Brownell
david-b at pacbell.net
Wed Sep 8 21:01:27 BST 1999
"Simon St.Laurent" wrote:
>
> This continues to be interesting, but I'm afraid you're convincing me more
> and more that your layered approach is grotesque, inflexible, and liable to
> tilt, rather than a good way to spare developers aspirin.
I find that puzzling. Layering is well known to be an essential
tool for managing complex systems. Heck, the proof is right in
front of me on my desk ... ;-)
> Again, you're assuming that everyone wants to treat Namespaces as a layer
> that happens _after_ XML parsing (incl validation) is complete. I don't
> want to move from XML 1.0 to Namespaces - I want to address Namespaces
> within the context of XML 1.0 validation.
But XML 1.0 doesn't include namespaces, so this can't be done. It's
a definitional thing. A revision of XML could do it, not that I'd
encourage such a thing right now. But it wouldn't be "XML 1.0" at all.
Some folk may be using validation in some other sense than the XML 1.0
specification defines it. If so, it'd help things to find some other
words or phrases to describe those processs -- at least apply adjectives
to disambiguate the various distinct notions.
> I don't find Namespaces compelling as a 'logical layer"
> lof their own - rather, I see their existence in a separate document
> as a historical accident.
Be that as it me, the _fact_ is that it's a separate and decoupled
document. If you hard-wire namespace conformance, you're no longer
conforming to the XML 1.0 spec, and vice versa. They're separate.
The only way to have them work in the same system is to use layers.
> > > Because XML 1.0 was written so that everything from character
> > > checking to entity replacement to attribute defaulting to
> > > structural inspections (DTD and otherwise) are all performed by one
> > > monolithic 'parser', we haven't been able to describe XML
> > > processors with any level of granularity. When I talk about layers
> > > (for instance, in
> > > http://www.simonstl.com/articles/layering/layered.htm), it's
> > > layering for the sake of breaking things into the smallest usable
> > > components, not for the sake of piling on more and more mostly
> > > redundant processing. Your layer 3 is way too thick.
Simon, what purpose is served by breaking things down that finely?
The flip side of recognizing layering as a useful tool is to know
that successful layers need to have a type of consistency that's
hard to create without careful integration. Even if it's not the
way I'd have integrated those components, XML 1.0 has that sort of
integration. Dis-integrating it shows no clear benefit to me; it
seems like reinventing the wheel or fire or something.
> >All of the layers are way too thick -- that's the joy of a high-level
> >logical model. I can break any one of them down into dozens of
> >smaller layers; in fact, the application layer will often be much more
> >complicated than the parser layer, simply because useful applications
> >generally do complicated things.
>
> Then maybe we'd better take a closer look at the layers you propose -
> piling many thick layers on top of each other doesn't sound like a very
> good recipe.
Hmm, that wasn't quite how I was taking it. While I'd admit that
many of the technology layers W3C is talking about seem rather thick
to me (== barriers to entry), what I heard David suggest was a way to
view those layers such that they didn't clash. (A role W3C should be
taking, but such architectural communication doesn't appear to be a
strong point over there -- sadly.)
- Dave
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 (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe 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