Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add XML collections classes for new CapiTainS guidelines #198

Open
sonofmun opened this issue Nov 11, 2019 · 11 comments
Open

Add XML collections classes for new CapiTainS guidelines #198

sonofmun opened this issue Nov 11, 2019 · 11 comments
Assignees

Comments

@sonofmun
Copy link
Contributor

Basically classes parallel to those in MyCapytain.resources.collections.cts

@sonofmun sonofmun self-assigned this Nov 11, 2019
@sonofmun
Copy link
Contributor Author

As far as I can see, the classes we will need will be for readable (I see no difference among editions, translations, and commentary that would require different sub-classes for these), work, and textgroup.

@PonteIneptique
Copy link
Member

Hmm, you should only have two classes, maybe three.

  • Collection
  • ReadableCollection
  • (?) RemoteCollection

@sonofmun
Copy link
Contributor Author

I can agree with that. The question then is should the metadata for a collection be read all the way down to its leaves? I.e., if the collections that are members of the collection that I am calling refer to non-readable collections with their own external __capitains__.xml, should that external xml file also be opened and the metadata and members extracted from that file? Or should only the information in the metadata file for the requested collection be shown?
My feeling is that it would be better to go all the way to all the leaves, but I worry that this may be too resource intensive for large collections.

@PonteIneptique
Copy link
Member

I need to think about it, my worry is how do you know the id of the children collection if you do not parse them (right now I think this is not hold in the schema)

@sonofmun
Copy link
Contributor Author

From what I see in the RNG in the guidelines, the identifier for the child collection must either be as an @identifier attribute on the <collection> element if it is a remote collection or as an <identifier> sub-element on the <collection> element if it is a local collection. So the ID should be available. But getting the IDs of the grandchildren, etc., would require parsing the 'remote' file.

@PonteIneptique
Copy link
Member

That's already the case with Capitains resources. It's the parsing using the local resolver that connects everything. For remote, I think the point is to give access to the id, but not actually retrieve the data. Though, maybe we should add a dc:title possibility for remote :/

@sonofmun
Copy link
Contributor Author

That seems less than ideal. If the remote source changes the title or something else, then it doesn't come over. I guess if the idea is that the user will always want to use their own title for remote resources, then that would be OK. Otherwise, best practice would say to get the metadata from the remote source. Perhaps we could add a parameter getremote so that the user can choose whether to follow the tree all the way to the leaves.

@PonteIneptique
Copy link
Member

PonteIneptique commented Nov 12, 2019 via email

@sonofmun
Copy link
Contributor Author

True. I guess I was thinking in terms of DTS there. Is it then expected that the provider of this remote source will give some kind of instructions for how to parse their metadata files? Or is remote meant to be completely independent of MyCapytain and Capitains in general?

@PonteIneptique
Copy link
Member

PonteIneptique commented Nov 12, 2019 via email

@sonofmun
Copy link
Contributor Author

OK. If the link is not a remote link? Should we go all the way to the leaves here, i.e., to all the readable descendants of the collection?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants