[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.
>>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx>
06/17/08 3:19 PM >>>
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”.
higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx]
Jim
Sermersheim
Tuesday,
June 17, 2008 2:08 PM
Higgins
dev <higgins-dev@xxxxxxxxxxx
[higgins-dev]
Model: Split EntityUDI into two types?
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.
|