nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

incomplete exif (now in content model)

jsauer

Hi,
I just figured out that from 3.4 onwards, Alfresco provides some exif tags within the original contentModel.xml

I am just wondering:
a) why is the list of properties limited to a subset 15 exif properties? (I count about 75 properties in the exif metadata extractor provided on forge)
b) why is the contentModel version number not being incremented? Still 1.1 should be at least 1.2, or do I miss something?

Kind regards
Jörg

Find more posts tagged with

Comments

mrogers

Which properties are mapped by the metadata extractors is configurable. There's two parts, the first is to obtain whatever properties are available in the source document and then the second part is to map those properties onto a data model in Alfresco. Clearly the default configuration is only selecting some of the more useful properties rather than everything.

jsauer

Hi,
thanks for the reply and hinting out the details how metadata extractors work to the readers of this forum.

My question was just about me wondering why you picked the exif prefix as it has already been used by many Alfresco users. Your properties within the namespace have different names to. So existing applications might be changed due to Alfresco using an commonly used prefix introduced by module. (OK I know one should ever work with fully qualified names using the URI, but who does)

So now there is an ambiguity for
exif:dateTimeOriginal

for example

To resolve it you get

{http://www.rightsassist.com/model/exif/1.0}dateTimeOriginal

and

{http://www.alfresco.org/model/exif/1.0}dateTimeOriginal

now your code really has to know which one to pick. I checked the code for QName.createQName(String qname, NamespacePrefixResolver prefixResolver)
which calls

String uri = prefixResolver.getNamespaceURI(prefix);
‍‍‍

which ends up in
NamespaceDAOImpl

    public String getNamespaceURI(String prefix)
    {
        if (! tenantService.isTenantUser())
        {
            return getPrefixesCtx().get(prefix);
        }
        else
…
…
    private Map<String, String> getPrefixesCtx()
    {
        return getPrefixesCtx(getTenantDomain());
    }
….
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Which handles prefixes in a Map 😞
So I wonder, which exif will win? Yours or the other one?
I have not checked this in debugger, but just from a quick static code analysis I think there is something missing here!

So the outcome of this is in my opinion:

never use a prefix, which is already in use (also for you guys)
use URI when possible
do not rely on NamespacePrefixResolver

Do you agree?
What to do about this?

Regards
Jörg

mikeh

I understand your frustration, however just a quick comment on this…

never use a prefix, which is already in use (also for you guys)

We can't possibly scan all forge or other 3rd party projects to discover which prefixes someone has decided to use. That may sound a little arrogant, but it's also realistic I would think.

Thanks,
Mike

mrogers

The namespace prefixes should be configurable and local to your context. What should be distinct is the "full qname" in your case {http://www.rightsassist.com/model/exif/1.0}. However if you have hard coded a prefix or are using an interface that dies not resolve local prefixes then yes there will be a problem.

With hindsight, What Alfresco should have done is reserved some prefixes, for example all ones beginning with "alf" however that pattern was not implemented in the early days so its a little difficult to start one now. Equally I think it may be useful if others reserve their own prefix namespaces.

jsauer

Hi Mike, hi M (also mike?),
thanks for your responses. I agree, no one can ensure there will never be a prefix clash. And no one will ask you to scan all forge modules. But there are some popular ones. And Exif / IPTC is out for quite a while and I think they are popular. So one could have expected that, for the obvious ones like exif, Alfresco could have checked before hand. (It is not even my module, I am just a user, and it is just being picked as an example. And if I am not mistaken there has already been the same thing with the mail (email?) prefix…)

Anyway, a good thing would be an example of best practice how to create interfaces that deal with prefix handling.

In code I can always use QNames having URI's, I could provide my own NamespaceResover etc. but for end customers to be able to configure things, I do not want them to handle URI based fully qualified names.

Example: Paramterized List Reports. Based on a template that pull in a list of columns (properties) to be displayed. If the column list looks like

cm:name
cm:title
custom:isbn
‍‍‍‍‍

This is much more likely to be accepted as is:

{http://www.alfresco.org/model/content/1.0}name
{http://www.alfresco.org/model/content/1.0}title
{http://www.mydomain.org/model/custom/1.0}isbn
‍‍‍‍‍

I would appreciate that in future we have some kind of reserved prefix list. Could be published on the wiki. Moderated or unmoderated.
And if one registers a prefix like alf, which is already reserved, the rule coud say that everything starting with alf_ is being reserved automatically. alfa_romeo would therefor still be possible for example.
alf_cm alf_d etc. does not look to bad, does it?

Regards
Jörg