Re:   json-to-xml namespace

HI,

Interesting considerations.
There is no blame, only evlution strategy development.

Just to wrap up the initial issue, removing the ns on import and putting it
back on export wasn't quite ... satisfying,
so I reconsidered and cut json out of the project. Its semantics
were twisting mine.
Now, instead, the application reads and writes firewall script (or shell)
files used to configure firewalls.
Luckily, those script files are relatively structured.

The best part is that without json compatibility considerations,
I could figure out a neat xml structure to better handle this.

As for the json namespace issue, I would put the data in no namespace, and
process it out when conflict arises.
Removing a dataset ns is overhead, but risks are low.
It seems that both probability and complexity increase somewhat with the
fn:ns.

Thank you all
Regards,
ac

Le mer. 11 dC)c. 2024, C  07 h 27, Michael Kay michaelkay90@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> a C)crit :

> >>
> >> The XML representation of JSON that XSLT  3 and XPath 3.1 define and
> share puts those elements into that namespace, like most XML vocabularies
> use a namespace.
> >
> > Wow. That's a shockingly bad choice of namespace URL, as if namespaces
> > weren't confusing enough already. Let's take elements that are neither
> > XPath nor a function and put them in the xpath-functions namespace.
> > Did nobody raise an issue here when the spec was written?
> >
>
> Of course it was debated at the time. There was a lot of concern about
> proliferation of namespaces and the fact that a minimal stylesheet
> contained three lines of useful code plus 25 namespace declarations, all of
> them totally unmemorable.
>
> Personally my instinct would be to make this a no-namespace document,
> which works well except when you want it schema-validated. There are lots
> of trade-offs.
>
> Using globally-unique names for everything leads to a lot of verbosity;
> the problem with namespaces is that they don't allow hierarchic scoping,
> something you would think we had learned was a good idea well before 1999.
>
> Michael Kay
> Saxonica