Re: question about XSLT namespace

On Fri, 2018-06-15 at 06:26 +0000, Geert Bormans
geert@xxxxxxxxxxxxxxxxxxx wrote:
> I bet you will get a lot of response here.... 
> 
> I am pretty much convinced changing the namespace with the version of
> any vocabulary is an extremely bad idea.

Agreed, and also with David's explanation.

Having the namespace tied to the language/vocabulary means developers
expect that you can dereference the namespace to import Java classes or
Python classes or a C++ library (or whatever language they use) to get
code that impements something based on that namespace, which is how
namespaces generally work in programming languages.

But that only works if there's a 1:1 mapping between names and
behaviour, and part of what i call the "XML Promise" is that any XML
tool is licensed by the XML specification to process any XML document.
You can use XQuery on a collection of XSLT documents and produce an SVG
visualisation of the number of templates in each; you can use XSLT on
an SVG document and make a list of colours it uses, and so on.

So the primary functions of namespaces have ended up being
(1) identifying a vocabulary (replacing formal public identifiers),
including triggering special behaviour, and,
(2) disambiguating names of elements and attributes, and hence making
it practical to mix vocabularies.

If we'd really wanted to replace formal public identifiers in the
document type definition with namespace URIs in the document though,
we'd have used a structured FPI-like syntax with date and version
fields, and the difficulties David Carlisle and others have mentioned
could have been avoided. The second use case I mention was the primary
one at the time, and assumed that editors would not be XML-aware.

Liam

-- 
Liam Quin, W3C, http://www.w3.org/People/Quin/
Staff contact for Verifiable Claims WG, SVG WG, XQuery WG
Improving Web Advertising: https://www.w3.org/community/web-adv/
Personal: awesome vintage art: http://www.fromoldbooks.org/