RE: use cases

Liam,

If the information in an unobtrusive namespaces file can be retrieved/created by xslt from an xml+namespaces document, should it not be reasonably possible that the result of processing a namespace-free document + a unobtrusive namespace file be equivalent to the result of an xml processor processing the equivalent xml+namespaces document ie effectively no data model differences?

In any case it might be a pain to have to deal with two files instead of one in the general case, but where a media type has been defined, as I was trying to illustrate with "neoxml", it could be a matter of the appropriate unobtrusive namespaces file being fixed by the the specification of the media type, and provided when necessary and appropriate via content negotiation on the specification URI for application/namespaces+xml.

Thanks
Peter
________________________________________
From: Liam R E Quin [liam@w3.org]
Sent: August 19, 2012 12:29 PM
To: David Carlisle
Cc: public-xmlhypermedia@w3.org
Subject: Re: use cases

On Sun, 2012-08-19 at 11:49 +0100, David Carlisle wrote:
> On 19/08/2012 11:27, Rushforth, Peter wrote:
[...]
> I must be missing something because I don't understand this at all.
> If a system can be configured to understand
>
> rel="ns" href="http://www.w3.org/XML/1998/namespace"
>
> Then it could be configured to understand href attributes generally, so
> presumably it could be similarly configured to understand any other
> hypertext related attributes such as src, it wouldn't really need the
> namespace mechanism would it?

The "automatic" part of my proposal was really intended to address the
HTML distributed extensibility in an environment in which too many
people had developed an xml-colon allergy. So I wrote it in such a way
that no colons were needed anywhere. However, it'd be pretty easy to
process the namespace definition file with XSLT and produce XML
documents marked up with prefixes.

> In your automatic namespace document you appear to be assigning
> namespaces to uprefixed attributes so this would mean the
> documents were not expressible in xml 1.0 + Namesapces. That isn't
> necessarily bad but it ought to be highlighted if it is true.

I'm providing a mechanism by which unprefixed attributes in the XML
input would be recognised as belonging to a different namespace and
moved automatically, rather like an HTML Web user agent moving a "math"
element into the MathML namespace (although I think in the end they
decided to take the Borgian approach and incorporate everything into
HTML, but that was still in question when I was first working on this).

You would in general get a different data model parsing an XML document
with an Unobtrusive Namespace Processor and a regular XML processor.

Liam

--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Co-author, "Head-First Namespaces", ORA, April 1st 2014

Received on Monday, 20 August 2012 00:38:31 UTC