OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] What is the rule for parsing XML in a namespace inside HTM

[ Lists Home | Date Index | Thread Index ]

From: Joshua Allen [mailto:joshuaa@microsoft.com]

>> 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 

>> 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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS