[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: What is the rule for parsing XML in a namespace inside HTM
From: Joshua Allen [mailto:joshuaa@m...] >> VML doesn't use the <xml> tag. It uses the namespace decl >> and a behavior CSS decl. >> The solution needs to work from >> those declarations, not a tag. OTW, the right way would be >Well, this is why I think the <xml> tag is a better solution, though. I >don't see why VML could not have done that. Specifying namespaced >markup (or really, any XML) directly in an HTML 4.x document is a design >flaw, IMO. It is at the very least a gaping hole in the current web architecture as realized by the aggregate specifications. On the other hand, with care it does work. I used VML precisely because I don't have to use a plugin and I have access to the DOM. I can use a database emitter to generate intelligent entity-relationship diagrams with popups, bubbles, a right-click navigation menu, and so on. Without the database source, the diagrams are unaffordable and unmaintainable. From that perspective, the technology is doing exactly what I need and I and my customers are very pleased because it is an impressive improvement over the old schema document based purely on HTML (big table monstrosity) both in look, ease of use, better comprehension, and so forth, at zero cost except for my coding time. But it surprised me that a missing end-of-comment decl could punch such a big hole into it. Given the emitter source and web distribution, a small mistake is amplified to a significant signal. So part of this is about tools and expectations, and part of it is noting that we have a seemingly permanent flaw in the web specifications. >> to insist when a namespace is embedded, that the wrapper >> document (HTML in this case) be conformant XML even if it >> isn't XHTML should the developer insist on >> well-formedness. We don't need more hacks. >This is not a bad idea. An XML system should behave as it is spec'd to behave. That's the exspec'tation. I realize that with HTML and XML being in conflict with regards to the Draconian parse model, that's a problem. IOW, if it doesn't work per spec for the simple applications like mine, it's not going to work any better for more complex apps. And I quite like the namespace approach using CSS behaviors because it is so easy to do... until it outs the parser collision. >The main issues I see here are: >A) It's a retroactive spec change for HTML user agents. As far as HTML >4.x spec is concerned, a namespace decl is no different from any other >attribute. So you would either have to change the spec, or come up with >a new spec for a class of "xml-aware HTML user-agents". Balmer just made a speech about how Microsoft will not become IBM and will continue to innovate. Such a spec if followed by Microsoft could be an important innovation. I realize the significance of Longhorn, but moving into a new apartment while leaving messy closets in the old one is really the kind of move IBM was famous for. Given that even with a slip of 1%, IE still has over 94% of the market, I don't think you have a fielding issue; you have a market issue over breaking existing content. >B) It's quite likely that the majority of web pages that contain VML are >*not* wellformed. For example, people use <link> tags or <p> tags that >are not closed. So even a change to the "xml-aware HTML user-agent" >behavior could be a breaking change for many users. Yes, but the reason for the Draconian parse rule was to get people to fix content and not make more malformed content. It does work as a strategy. I've seen some dramatic improvements here where people who don't like to talk have to because the XML engines won't let them ignore such things. Anyway, the <p> tags are in the HTML namespace. The VML just gives their content a piece of pixel space. So as TimBL is rumored to have said about URLs, 'let them break'. >Also, if I were to write a spec for a class of "xml-aware HTML >user-agents", my strong preference would be to go with the <xml> >convention. Then from that, spec how user-agents validate the contents >of <xml> block. I think the <xml> block could have been a really nice >convention for plugging in extra validation, registering plugins based >on namespace, etc. Maybe but you can't use that string and not break the XML spec. If you insist on using a tag, use another one: <ms:container validate=".T." ></ms:container> or even a poor old processing instruction (that's what they are there for). If we have to break content to get a more reliable web, it's worth it. (I wonder how much content out there is static and how much is generated. Would it be worth fixing the generators? I think it would but that's a good debating point.) >> What happens when we get to XAML? >This is the other side of the coin. In the case of XAML and WordML, >both of which can contain VML, the envelope already *is* XML, and is not >processed by an HTML browser. The user-agent is already operating in >draconian mode. So in that case, the <sml> convention would be >unnecessary (and in fact non-wellformed). Right although when I put VML into a Word doc, I get a nasty scaling surprise and I haven't had time to work that one out. However, the drift of this is that all of the innovation for an NGbrowser will be in XAML and HTML will stay as it is. If that is the message, so be it. I've doubts about that as a market strategy although as the MID guy, I've confidence that it is the right answer as long the rendering and behavioral systems are separate but perfectly meshed. It is risky but as Balmer said, we should only quit using MS products when MS quits taking big risks. Ok. I've done enough to keep Edd's Len rating in two digit numbers. len
|
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
|