| RE: [higgins-dev] Model: Split EntityUDI into two types? |
|
So, where we ended up on the IRC was that we would like to have two data types. One that represents an absolute entity UDI and one that represents a relative one. The relative entity UDI would simply be a string, yet when it becomes pared with a context ID (as soon as it gets turned into an absolute UDI) it needs to be properly encoded.
Are you saying that if the scheme part of an entity UDI is missing then we can assume it's relative?
[sorry, answering in reverse thread order]
Jim, on #1, the absolute/relative determination is per the rules in RFC 3986. They apply to XRIs, IRIs, and URIs. In short, you look for a scheme identifier or not.
On #2, it’s true that the relative entityID would not need to be encoded if it was only used locally. But as soon as it will be passed anywhere as part of an absolute UDI, it MUST be deterministically encoded or all hell will break loose.
=Drummond
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of
Jim Sermersheim Sent:
Wednesday, June 18, 2008 12:31 AM To:
'Higgins (Trust Framework) Project developer discussions' Subject: RE: [higgins-dev] Model: Split EntityUDI into two types?
On #1, how does one make this determination? I mean, if I presented some string to you and said: "this is a UDI" what logic do you perform to determine whether it's relative or absolute?
We talked about #2 on the IRC. Markus suggested that a relative entity UDI could be an unencoded entity ID whereas an absolute entity UDI would need to have its "entity ID" part encoded. This seemed like a good solution.
Jim, two issues:
1) All currently contemplated UDIs (which all derive from URIs) are unambiguously absolute or relative. So, if you want, you can always determine this from the UDI value itself.
2) The difference between a relative UDI and a string is that a relative UDI requires encoding as a valid URI, whereas strings can contain spaces and other non-legal URI characters.
My own POV is that this encoding is: a) trivial, and b) deterministic transformation in both directions, so it would indeed be easiest to just have the EntityID be a UDI and be done with it. That’s also “the Web way”.
=Drummond
From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx]
On Behalf Of
Jim Sermersheim
Sent:
Tuesday, June 17, 2008 2:08 PM
To:
Higgins dev <higgins-dev@xxxxxxxxxxx
Subject:
[higgins-dev] Model: Split EntityUDI into two types?
Paul,
Right now the 1.1 model allows a higgins#entityId to have values of types: higgins:EntityUDI, and xsd:string.
If the value is of type higgins:EntityUDI, there's really no way of knowing whether it's relative or absolute.
Could we instead make higgins#entityId allow values of higgins:RelativeEntityUDI and higgins:AbsoluteEntityUDI?
If CP's are going to be able to dereference entity UDI values, they'll have to know whether the values are relative or not.
If we did this, we wouldn't actually need xsd:string to be one of the allowed value types. As I understand it, a relative entity UDI would be exactly the same as our old-style entityID strings. So since they are syntactically and semantically equivalent, there shouldn't be a need for xsd:string.
Jim
|