I'd like to draw your attention to the planned URE API change
<https://gerrit.libreoffice.org/#/c/77861/> "[API CHANGE] Adapt css.uri
UNOIDL entities to RFC 3986". The original implementation of
css.uri.UriReferenceFactory et al was based on then-current RFC 2396
(<https://tools.ietf.org/html/rfc2396> "Uniform Resource Identifiers
(URI): Generic Syntax"), but which has long since been obsoleted by RFC
3986 (<https://tools.ietf.org/html/rfc3986> "Uniform Resource Identifier
(URI): Generic Syntax"). Conformance with the new RFC required some
changes in behavior of those UNOIDL entities, mostly around corner
cases; for details see the list below, extracted from the commit message.
If there is no objections over the coming days, I'm going to push this
to master soon.
* XUriReference.isHierarchical is obsolete and deprecated.
* The behavior of XUriReference.hasAuthority, XUriReference.getAuthority,
XUriReference.getPath, XUriReference.hasRelativePath,
XUriReference.getPathSegmentCount, XUriReference.getPathSegment,
XUriReference.hasQuery, and XUriReference.getQuery has been made consistent
for all URIs, no matter whether they were considered hierarchical or opaque in
the past.
* The behavior of XUriReferenceFactory.makeAbsolute and
XUriReferenceFactory.makeRelative has been changed to match the RFC 3986
reference resolution specification. The XUriReferenceFactory.makeAbsolulte
parameter processSpecialBaseSegments has been renamed to
processAdditionalSpecialSegments, as per the updated specification it now
controls treatment of special segments in the given uriReference, in addition
to special segments in the given baseUriReference. (Renaming UNOIDL interface
method parameters is technically an incompatible change, but the benefits of
improved clarity presumably outweigh any potential drawbacks in this case.)
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
