Hi Pawel,
Il 30/04/2025 12:32, kowa...@denic.de ha scritto:
Hi Mario,
Thanks for clarification. From draft-ietf-calext-jscontact-profiles-00
I interpreted that "localized Card replaces one or more top-level
properties entirely" means full replacement. Partial replacement would
be fine with a small issue of removing items, as then all what
localisation could do is setting null. But I think it's not that wrong
at the end.
[ML] That sentence clarifies that if you want to localize the entire
card, you can but this means that it will entirely be replaced. That
doesn't apply when you localize single objects, otherwise the example at
page 7 wouldn't work.
As a side note then - your code does not seem to have any logic of
looking up main object if it's not existing in the localisation. In
normal use one would need some logic for this.
[ML] The project only aims to demonstrate that implementing JSContact
for RDAP could be very easy and doesn't need specific features like
JSONPointer to handle localizations.
Anyway, I just added a method to the Card class to get a localized
version of a card and the related test.
I purposefully didn't use Java reflection or JSONPointer to be more
straightforward and leverage only basic features. The convention set by
jscontact-rdap of localizing the topmost objects facilitated the job.
The jscontact-tools library includes a more elegant and sophisticated
version of the same method as it must be more flexible.
Best,
Mario
In pure context of RDAP the issue is indeed less relevant, as EPP
servers have 2 distinct copies of data for each int/loc variant, so
rendering a partial diff out of it would be more of a trouble than
help, so full replacement variant would be likely the one used anyway.
Kind Regards,
Pawel
On 30.04.25 12:16, Mario Loffredo wrote:
Il 29/04/2025 16:51, kowa...@denic.de ha scritto:
Hi Mario,
This is very straightforward. My concern is in the data consistency
and redundancy.
You have a very nice example, where just postOfficeBox and
countryCode are not localised.
And even in this example if the localisation would set different
countryCode the dataset would be inconsistent, maybe leaving even
room to some misuse.
If the dataset would contain much more properties which are not
being localised - tel/fax/email/vatid etc. then there will be a lot
of redundant data where the implementation would either need to
decide to close eyes and just trust they have the same content or
implement some consistency check and error handling. All not nice.
Putting all trust in implementers of object creators (RDAP servers
in this case) will render errors IMHO.
In the context of RDAP redaction would be more complicated as for
each object there would be more paths to cover - at least as long as
JSONPath is in use. However still easier or even possible compared
to the original patch objects.
[ML] Properties that don't need to be localized are not required to
be included in the localizations property.
I just updated the test by including the phones property that must
not be localized per what is defined in rdap-jscontact doc,
In theory, you could even localize only the nested properties that
can be language-dependent and ignore the others. Looking at the
example in the test, you could exclude the country code and P.O.
information from the localizations property.
The choice to localize the entire address reflects the way int/loc
addresses are represented in EPP.
Honestly, the JSContact localizations property looks to me more
similar to the EPP PostalInfo element than a data structure providing
int/loc versions for each of the nested elements.
Additionally, please consider that not only text values can be
localized in JSContact. For example, you might provide an audio/video
message in different languages.
Therefore, to provide language-dependent variants along with the main
information and keep the flexibility of the current proposal for
localizations, we should implement a "LocalizedObject" type more than
a "LocalizedString" type (quoting the text in a previous Robert's post).
Best,
Mario
Kind Regards,
Pawel
On 29.04.25 12:40, Mario Loffredo wrote:
Hi,
just made a simple project on GitHub
(https://github.com/mario-loffredo/TestJSContactProfile) to
demonstrate how it would be easy to implement the JSContact profile
for RDAP.
The test at
https://github.com/mario-loffredo/TestJSContactProfile/blob/master/src/test/java/testJSContactProfileForRDAP/LocalizationsTest.java
is executed on the JSContact card reported in Figure 1 of
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/.
The uid property has been removed. As for localizations, I think
the solution described in the JSContact profile document is the
best way to go, as it preserves the efficiency and flexibility of
the original proposal and, at the same time, allows implementers to
handle localizations without having to deal with JSONPointer.The
test project demonstrates that, using basic Java features (and I
imagine that the same features are available in all programming
languages as well), an implementer can deserialize a JSContact
card including the "localizations" property into a simple data
structure.
Any feedback is appreciated.
Best,
Mario
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
