RE: [xml-dev] "Introducing MicroXML, Part 1: Explore the basicprinciples

["Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>]

> 
> On 04/07/2012 13:39, Rushforth, Peter wrote:
> > I'm guessing that in xml parsers today they would not do 
> much.  What 
> > does an xml parser do with xml:base value?
> 
> In parsers that support xml:base they use it to resolve any 
> relative URI specified in SYSTEM entity references. If they 
> also support xinclude they presumably use it to resolve 
> references in that case.

So, I guess those parsers could also resolve xml:href and xml:src references,
and leave the interpretation of the link typing to be worked out
by the application.  

> Given that a large part of xml _on the web_ is xhtml and that 
> uses href rather than xml:href,

I gather you don't often see application/xhtml+xml in the wild?

> I still don't think you've 
> provided any use case where an application that understood 
> this new xml:href proposal couldn't just as simply understand 
> an href attribute.

Of course it could, but libraries can be re-used, so if the affordances
are built into one namespace (xml:), then a library can be written
to provide services to applications across many use cases.

Earlier you mentioned:

> Note even in (x)html href doesn't -always- denote a link 
> (although that was proposed for xhtml2) Html href only 
> implies a link on certain pre-specified elements. So the fact 
> that href in unknown xml does not imply any linking behaviour 
> is entirely consistent.

So, in xml:, href is a link.  Then a library can work with it.  

Backwards compatibility is very important because of all the content out
there already.  That's why attempts to get html into xml and vice versa 
won't work.  text/html will always rule on Web 1.0.

But, Web 2.0, Web 3.0 etc are a different story.

Peter