-
Notifications
You must be signed in to change notification settings - Fork 10
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 aliases (short names) for set definitions. #31
Comments
Good idea, I'd suggest calling them alias rather than label perhaps, as label is something in set definitions already (the human readable label). |
I added an 'alias' mechanism to libfolia. In the 'alias' branch for now, as it imposes an ABI breach. |
Still to be implemented for pynlpl (proycon/pynlpl#33) |
Well.... <?xml version="1.0" encoding="UTF-8"?>
<FoLiA xmlns="http://ilk.uvt.nl/folia" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="doc" version="0.8" generator="libfolia-v0.4">
<metadata>
<annotations>
<division-annotation set="a-set" alias="a"/>
<division-annotation set="b-set" alias="b"/>
<token-annotation set="a-set" alias="b"/>
<token-annotation set="b-set" alias="a"/>
</annotations>
</metadata>
<text xml:id="text">
<div set="a-set">
<s id="s.1">
<w id="w.1" class="WORD" set="b">
<t>test</t>
</w>
</s>
</div>
<div set="b">
<s id="s.2">
<w id="w.2" class="WORD" set="b-set">
<t>test</t>
</w>
</s>
</div>
</text>
</FoLiA> libfolia's folialint accepts it, but pynlpl's foliavalidator says:
which is right here? |
Right, that is addressed and solved in #65 (to be release still), so I think we can close this one. |
At the moment, having more then one annotation set in scope, leads to a lot of bloat, example:
set="https://raw.githubusercontent.com/proycon/folia/master/setdefinitions/frog-mbpos-cgn"/>
and especially
set="http://ilk.uvt.nl/folia/sets/frog-mbpos-clex"/>
are repeated a lot
Maybe it is a plan to introduce short-hand labels, like
cgg-set
andcelex-set
to avoid all the bloat.Something like this:
Everywhere a set is used, you may use the label instead. When serializing the label, if provided, is preferred.
Labels must be unique of course
The text was updated successfully, but these errors were encountered: