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

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

Hi David,

> 
> On 25/06/2012 16:39, Rushforth, Peter wrote:
> > So code-on-demand would work not only for HTML, but also more 
> > powerfully, for anything XML.
> 
> It would be a really retrograde step to force certain named 
> attribute/elements to have _fixed_ semantics. That is by 
> design one of the main differences between using a 
> language-specific markup such as html and a generic markup 
> such as xml. 

Well, of course if the semantics in the root namespace don't fit
the bill - perhaps the 20% use case(?) - invent your own or add to them.
That's what's great about XML, right?

> It is (more or less) OK to do this for things in 
> the xml namepsace, but certainly not for all href attributes 
> for example). Even something like xml:id is sort of OK but 
> its benefits are rather limited as usually you don't want to 
> use a fixed name, you want to use a name that fits with the 
> application design. (id for example).

Well, xml:id is a bit funny, I admit, because what you want to
put in it should up to the client not XML.  But maybe it has benefits;
I've never had to use it.

However, xml:base is a bit closer to home, since it controls the
location of the resource for the application.  If it's important
for where this resource is to be in that namespace, why isn't it
important for where other resources are (href, src, tref)?  
And, what they might mean (@rel, @type - RFC 2046, @hreflang)?

The latter is of course related to xml:lang, which describes what
parts of this representation mean.

Other stuff like title I think is less important, and does not need
to go into the root namespace - does not really control what the application
does with the link, except presentation - invent away!


> This has always been a 
> fatal flaw in xlink (and explicitly why it was never adopted 
> in xhtml2 drafts as using html-specific attribute such as 
> href and src were always going to be more popular _in html_ 
> than xlink variants of the same).

Well I'm just sayin' :-).

> 
> If you want the xml to be treated as html with <link elements 
> associating scripts and stylesheets etc, and href acting like 
> xhtml:a/@href then supply an xslt stylesheet that expresses 
> that behaviour.
> 
> 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.
> 
> If you modify your browsers default xslt (or if you serve the 
> xml already associated to a non-default xslt) then you can 
> already do everything that you ask. If you serve xml in an 
> unknown vocabulary then it is right that the browser does not 
> interpret it at all and just shows it verbatim (with 
> optionally syntax highlighting applied) to do anything 
> different would be confusing, or dangerous or both.

I don't think you can modify the browser's default XSLT, right?
That's not code-on-demand, it is a client configuration tool.
You're right, it might be dangerous to allow that I think.  
So if the browser natively controls what gets presented as a link,
it has its own security paradigm that it follows, for example
preventing cross-site scripting etc.  How it recognizes cross
site scripting is because I think it only allows xhr requests for
code on demand, with the exception of json, which it can
statically analyze, perhaps.  Just guessing here.


> 
> But actually I'm confused. This thread is about microxml so 
> given that browsers already do full xml so are presumably 
> highly unlikely to do microxml as well, how would adding 
> pre-defined semantics to xml:link in microxml help or hinder 
> the use of xml on the web?

I really apologize, but I thought that was what MicroXML was about -
helping advance the use of XML on the Web.  

If not, I will stay out of it.

Peter