[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#20339: Taking a step back (was: sxml simple: sxml->xml mishandles na
bug#20339: Taking a step back (was: sxml simple: sxml->xml mishandles namespaces?)
Fri, 3 May 2019 12:46:27 +0200
after mulling over it for a while, I think it's time to take
a step back and think a bit about where we'd like to go with
Note that I'm ignoring technical details (the fact that the
SXML, and thus the XML serialization now has namespace declarations
everywhere down the path instead of just at the corresponding root
node, and the thing with the default namespaces, as noted in ,
seem to me "fixable" technical details).
Your patch, Ricardo, takes a new approach wrt. the SXML resulting
from an XML parse: the full tag names (the QNAMEs, in XML parlance)
are now composed of <prefix>:<name> (mimicking the XML) instead
of <namespace uri>:<name>, as the former (sxml simple) used to
do. This has upsides and downsides.
I'll call your approach the "prefix" approach (as having the
prefixes to qualify the tag names) and the approach followed
by (sxml simple) up to now the "URI" approach, which haves
the full namespace URI qualifying the name.
In the URI approach, a qualified tag name would look like
whereas in the prefix approach, it'd look like
plus the knowledge somewhere that the prefix "myns" stands for
myns -> http://example.org/namespaces/myns
Upsides of the prefix approach:
+ it mimics more closely the XML syntax. Since that
is what the XML folks see, that follows the "principle
of least astonishment" (aka POLA)
+ it is forced to keep the prefix -> namespace associations
(it would be semantically incomplete if not, since what
counts semantically is the namespace URI)
- it contradicts current documentation
"All namespaces in the XML document must be declared, via
xmlns attributes. SXML elements built from non-default
namespaces will have their tags prefixed with their
URI. Users can specify custom prefixes for certain
namespaces with the #:namespaces keyword argument to
This can be changed, of course :-)
But perhaps someone is already relying on it?
- working on the resulting SXML becomes harder, because
to compare two qualified names, we'd have to resolve
the namespace associations.
Upsides of the URI approach
+ it is what the documentation says
+ it follows more closely the XML semantics (the namespace
prefix in itself is irrelevant after all). As a corollary,
working on the SXML becomes easier: a comparison of two
qualified names becomes a simple string comparison, etc.
I think that is why (sxml simple)'s original design followed
Well, negate the "prefix approach" upsides :-)
Let me just say that there seem to be precedents for the
prefix approach out there in the 'net: the Wikipedia
article  (yes, there's a wikipedia on that!) follows
the prefix approach. This nice blog post  too.
I think I'll stop here. Mi fingers itch with some hacking,
but I think we should pause and ponder before hacking.
Perhaps we should take this to guile-devel? OTOH, if someone
knows The Way Forward (TM), I'm willing to hack in this
Cheers & thanks
 Message ID <address@hidden>
Description: Digital signature
|[Prev in Thread]
||[Next in Thread]|
- bug#20339: Taking a step back (was: sxml simple: sxml->xml mishandles namespaces?),