Lists Home |
Date Index |
- From: "Simon St.Laurent" <email@example.com>
- To: firstname.lastname@example.org
- Date: Wed, 08 Sep 1999 15:53:44 -0400
At 12:03 PM 9/8/99 -0700, David Brownell wrote:
>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 ... ;-)
The problem isn't the use of layering itself - it's the choices about what
kinds of layers are used and what 'logically' qualifies as a layer.
>> 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.
I'm not especially concerned about it being "XML 1.0" at all. Yes, I'll
happily acknowledge that integrating namespaces and XML 1.0 in a strong
sense would require rewriting, probably resulting in XML 1.1 - which no one
seems interested in doing.
Proposing it in a weaker sense might encourage consistency among those who
need and use it, however. It doesn't seem like decoupling DTD processing
from XML 1.0 is especially difficult, and that integrating that with
namespaces in a better way (in fact, any way) than exists now would be useful.
>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.
Agreed. We need better vocabulary. After a few years in the language
lawyering world of XML 1.0, 'validation' to me means something that happens
in XML 1.0 with DTDs. If I need to describe schema or RDF applications, I
tend to say 'schema validation' or 'validation against a schema', for
>> 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.
In other words, we're stuck, should wait for schemas, and should
discontinue use of DTDs in systems where namespaces may be important? (And
I mean namespaces, not namespace prefixes.)
I suspect that there's a sizable number of developers who might like more
options than that.
>> > > 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?
Lots of purposes. You can reuse modules easily, integrate new technologies
(like namespaces) into existing structures, and take modules that were
originally built for use in parsing and apply them to results from other
XML operations (like XSL transforms, DOM work, etc.).
>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.
If reinventing the wheel would let me reuse the wheels on other devices,
I'd be happy to do it. Right now, XML 1.0 provides you with axles, wheels,
and tires, all glued together so that you can't take the wheels off and put
them on another car without yanking the axle off.
Integration is critically important. A key part of integration, though, is
clarifying the parts and how they fit together - and come apart.
>> 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.
I agree with David (Megginson) that the layers shouldn't clash. However, I
don't think his model avoids clashes successfully (notably DTD validation
and namespaces), and I consider the thickness issue important. If you're
willing to break down some of those layers, I think you'll see lots of room
>(A role W3C should be
>>taking, but such architectural communication doesn't appear to be a
>>strong point over there -- sadly.)
Agreed. There are a few documents out there that might be guideposts (like
the Notes I mentioned earlier today), but they don't provide a clear
picture of where any of this is going. There seem to a large number of
very different perspectives. Hopefully those different perspectives will
play off each other and give us some useful tools.
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)