[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Model: Split EntityUDI into two types?
|
> Jim wrote:
> "Are you saying that if the scheme part of an entity UDI is missing then
we can assume it's relative?"
Yes. That's the RFC 3986 test. The only ambiguity is that a relative URI
that does not begin with // or / and whose first segment contains a colon,
i.e., "xxx:yyy" could be a relative URI but it looks like an absolute URI
with scheme "xxx". To avoid this, you must follow the rule defined in
section 4.2 of RFC 3986:
A path segment that contains a colon character (e.g., "this:that")
cannot be used as the first segment of a relative-path reference, as
it would be mistaken for a scheme name. Such a segment must be
preceded by a dot-segment (e.g., "./this:that") to make a relative-
path reference.
=Drummond
_____
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Wednesday, June 18, 2008 2:08 PM
To: 'Higgins (Trust Framework) Project developer discussions'
Subject: 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?
>>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 06/18/08 2:00 PM >>>
[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 >>>
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
_____
size=2 width="100%" align=center tabindex=-1>
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
