its: support metainfo files with set namespace - #777
Conversation
Match libappstream and only operate on the local name, irrespective of actually set namespace.
|
There is no namespace for AppStream Metadata that we defined - so shouldn't we rather make that namespaced stuff fail validation and reject it outright? Either that, or we do officially define a namespace, but until we do that, I think we should just reject namespaced data, since it is not compliant with the specification (which, while not explicitly forbidding namespaces, does not name one and has no example of using one). |
|
I know that using a namespace is 'discouraged', but the way I understand the manual, adding |
|
Right, I forgot we added that... It is not at all a great idea in pretty much all cases, and I am not even sure it validates correctly, since absolutely nobody tests this. Why do you need a namespace? Why can't you just drop it? |
It does, since libappstream really only ever gets the name of the node trough
The application manifests gtk-android-builder operates on, are expected to embed an appstream manifest within I did originally implement it that way instead of the other way around (pixiewood information within appstream custom tags), due to the custom tags not being flexible enough for storing the multi-layer application icons and by now the pixiewood manifests contain stuff that really shouldn't be part of the appstream manifest (configure options, etc.) |
|
The metainfo.its shipped as part of GNU gettext has essentially all its rules duplicated, one set with the While this technically doesn't match what libappstream is doing, that approach would work for me too, should you prefer it. |
Match libappstream and only operate on the local name, irrespective of actually set namespace.
Kinda nasty, but sadly necessary when having to deal with namespaced and namespaceless files :/.