Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Reserved names and documentation
 At 05:46 PM 1/5/99 -0800, Tim Bray wrote: >There is at least an "XML Co-ordination" group whose job it is to worry >about such things. Simon is right that the picture is pretty complicated. I'd love to see a set of goals from the higher level group like the working groups below it have so successfully produced. Right now, the emperor himself is pretty invisible to the outside world. There's no broad statement of what the XML family of standards should look like when it reaches maturity (or puberty, even.) I think everyone on this list has their own, usually incompatible, vision of what XML should look like. A statement of what it will look like might give us something better to work with, introducing less complication in the long run. We've also got lots of specs and no clear order on how to process them. Do you parse the document first and validate it, then inspect it for links, then transform it, then format it? Or do you parse the document, transform it, validate it, inspect it for links, then format it? Or do you parse the document first and validate it, then transform it, then inspect it for links, then format it? And where would namespace processing fit in there, amongst the transformation (of the DTD?) or the validation? Yikes. Saying you can order these things any way you want is going to explode a lot of XML's interchangeability, damaging Paul Prescod's assertion that "[XML] is optimized for interchange, interchange and interchange." >>Namespace prefixes hate >>validation. > >[plausible but complex DTD transformation algorithm to accomodate >prefixes and namespaces] > >Thus, I have to reject Simon's contention that namespaces are >anti-validation. It is true that *compound documents* pose big >problems for document design in general and validation in >particular. Compound documents, it is painfully obvious, are >coming at us fast, and in high volume, so it behooves us to get >our act together on document design. Namespaces, for the nonce, >allow us to have compound documents without the elements falling >over each other. But in and of themselves, they don't particularly >impair validation. In and of themselves, they make validation far more difficult, requiring a transformation of DTDs for which there are no standard tools. Given that validation is built right into the parser in many implementations, it's kind of hard to slip in and fix the DTD after realizing that you've got a prefix change on your hands. Better parsers might be capable of doing this; I'd rather see layered processing, where one layer checks syntax, and another checks document structure. That way we could sneak in for DTD transformations and other weirdness. Unfortunately, there hasn't been a lot done in the XML 1.0 spec to accomodate or promote such a model. (The Lark/Larval implementation that Tim's built might allow such possibilities; I'll have to take a closer look.) I don't think too many people are actually going to try that algorithm, and namespaces are going to have to wait until schemas arrive that can handle them. (Schemas will also probably help with my layering issues described above.) >>XLink provides services that seem to overlap with entities, no >>matter how much some insist that the don't > >Yup. Who insists there's no overlap? Obviously, since XLink is >trying to be a general-purpose hypertext mechanism, and external >entities have an obvious hypertext semantic, it would be surprising >if there were no overlap. So much so that some have suggested that >once we have hyperlinks we don't need entities any more. >I doubt that, but it's a sane premise worth considering. But the >overlap doesn't feel dangerous to me; what should we be worried about? The overlap may not feel dangerous, but the very existence of an overlap does make people wonder - a lot. Having multiple ways to achieve similar goals using totally different syntax is usually not considered elegant. Elegance may not be a design goal for XML, but it certainly would help on the coherence issue. >>, and the PI used for style >>sheets provides yet another example of connecting resources using URLs. > >That's evidently an interim patch made necessary by the imminence >of the R5 XML-capable browsers... the right solution is a general-purpose >packaging mechanism so you can bundle up an instance with pointers to >(or direct inclusion of) the stylesheet(s) and schema(s) and scriptware >and so on. But that's going to take some real work to build. Glad to hear it's a temporary fix. I hope we don't see too many more of these temporary fixes. XLink should be able to help with this, when it finally arrives. >>CSS and XSL are mutually >>incompatible tools that do a lot of the same things. > >That's a real live problem all right; but at least everyone knows >it exists. -T. Everyone knows it exists, but it goes on... Coherence is important. XML has great potential, but it also has great potential to bury itself in complexity. (I think) David Megginson said a long time ago that XML would be doing well if every iteration of the spec was smaller and simpler. Unfortunately, that doesn't seem to be the direction XML is heading. Simon St.Laurent XML: A Primer / Cookies Sharing Bandwidth Building XML Applications (February) http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
