[mdx] syntax for entity-attributes

[Ian Young]

On 3 Sep 2014, at 19:46, Tom Scavo <trscavo at gmail.com> wrote:

>> then it immediately makes sense to define syntax to represent selection on that basis. It's only reasonable, I think, to define such a syntax if you want to attach semantics to it
> 
> I really don't see why that is.

We need to agree to disagree, then. Inventing syntax with no semantics is just adding a (literally) meaningless constraint. I think that's rarely if ever a good idea.

>> in other words, if you want to revisit the question of turning this into a search protocol. I still feel quite strongly that this is something that we do *not* want to do in either of these specs, although we might want to implement or profile something more specific later.
> 
> I strongly agree with your strong feelings against a search protocol
> ;-) but what does that have to do with a syntax for entity attributes.
> The latter is an agreed upon syntax for a particular aggregate (not
> unlike the proposal for a syntax for the "all entities" aggregate),
> which seems to me to be a rather Good Thing.

If we refactor out the special meaning of '{' from the protocol document, identifiers are completely opaque strings. What that means is that you can use any string you like to represent any thing you like. What I'm missing from what you're saying is any real benefit to defining *in the protocol document* any structure to the identifiers presented.

>> As Scott says, where we ended up last time round this loop was to observe that you can define any identifiers you like. They can even look like they have some kind of internal syntax associated with them if that's of assistance; but ultimately the identifiers presented to the query protocol are opaque and any apparent structure within them has no defined meaning, as I said before.
> 
> Yup, okay, I can buy that. Can we say the same about the "all
> entities" aggregate? Or do you think that's fundamentally different in
> some way?

In the original concept, that was at a different location (/entities rather than /entities/ID) rather than having a specific identifier syntax, so the question didn't come up. It's a legitimate question as to whether allowing an empty identifier (currently forbidden by the spec and my implementation) and defining that means the "everything" aggregate as well is a benefit. I mentioned this in a footnote to my last mail for completeness, but (spoilers) I'm inclined against it.

>> We've already refactored a lot of the "{sha1}" mechanism so that it is now mainly defined in the layered SAML document. However, I attempted to make a generic mechanism out of that; in retrospect I think that was the wrong approach. I now propose to state in the base document that an identifier (a thing passed to the query endpoint at .../entities/) may be any string of encodable characters (in ABNF, "1*idchar" instead of "notlb *idchar"[1]) and thus pushing all special cases out of that document into profiles, such as the SAML profile.
> 
> Hmm. What if a server chooses to support the "{sha1}" mechanism only,
> leaving the client to do the mapping (say, with JavaScript)? I don't
> think we want to force the mapping on the server, do we? (In fact, we
> have a deployed client-server setup based exactly on this assumption.
> The server implementation is intentionally "brain dead" in our case.)

I'd want to fix some of the wording in the SAML document to make it clearer. What I think it should say after refactoring is that every SAML entity is regarded as having two identifiers:

* the natural identifier taken from its entityID

* a secondary identifier constructed by {sha1}xxx-ing that entityID

These are actually the semantics I ended up implementing (as you can perhaps see if you look closely at the browser rendering of query results), the spec is currently pretty vague about some of the edge cases but this would fix that.

This is the kind of ambiguity I knew I'd uncover by implementing, so I'm really glad I did the work.

To your question, though, the server *can't* decide to only implement the {sha1} form of identifier without becoming completely useless to the current client, which uses the entityID when it has it, and only uses the {sha1} form when that is all it has (in the Artifact profile, as I recall). So implementing both *for entities* is a MUST.

> 
>> Comments on this proposal?
> 
> I think we're too early in the deployment phase to be making firm
> decisions (but we should continue to discuss, to be sure). Methinks
> the spec should bake for awhile as folks get more experience deploying
> this stuff.

OK, noted. Others?

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20140903/01ce351d/attachment.bin>