Time: 4:30 PM EDT
Zoom:
Zoom Link:
http://tinyurl.com/48n4yrzsMeeting ID: 850 9753 8468
Minutes for 10 October July 2024 TC Meeting
I. Roll Call & Minutes
Voting members
Hal Lockhart (Co-Chair)
Bill Parducci (Co-Chair)
Steven Legg
Voting Members: 3 of 4 (75% - quorum)
Approve Minutes for 12 September 2024 TC meeting
https://groups.oasis-open.org/discussion/minutes-for-12-september-2024-tc-meetingII. Administrivia
GitHub “cc” to List update status
Bill:
It looks like this is working. Just need to be careful not to use email to reply to
an issue because the header tracking gets lost and the entire thread will get
reposted in the response.
Email archive status
Bill:
No update from Oasis
Attendance
Attendance at the 12 September TC meeting was clarified. Hal, Cyrill and Steven were on
the call.
Meeting times
The next meeting is scheduled for 7 November 2024 at 2:30PM for Daylight Savings time
shift in the US. The TC is open to shifting hours of meetings to best accommodate local
times for members.
III. Issues
Hal:
We're open to discuss issues that have been raised on the list/GitHub
Steven:
The most important issue is about how we break up the specification. So I started a
discussion on making the core syntax agnostic. And I provided an example around the
policy definition of what that would look like as I explained to Cyril in some of the
commentary on GitHub. I wasn't looking to incorporate any of the other things that we
were talking about and I wasn't looking to fix the text. I basically just took the text
as it was currently and just restructured it so that the XML or XML schema parts of it
could be factored out into a separate profile.
So the decision before us is do we want to do it? And do we want to do it in this way to
make the core specification not favor either JSON or XML.
Hal:
I favor that.
Bill:
Agreed. I think that's a great way to go. I think that fundamental work at the core of
the policy is something that may end up being forked or used otherwise, but is really
good stuff that I think stands on its own.
Steven:
So related to that then is the question of what do we call all this stuff, Cyril in the
last piece mentioned, we do a poll for this and it seems like a good idea. I assume that
if we do a poll within oasis, then it's just going to be a poll of the voting members,
which isn't all that useful. And we want a wider audience of that.
Bill:
It's pretty trivial to set up a simple poll using a Google Doc form and then maybe what
we could do is ask Oasis if they could send it out to the general list. And then we
also take that link and send it over to anyone else that we think might be interested.
Steven:
I assume when you set up the poll, you get a link and you can just advertise a link
wherever?
Bill:
Exactly. And then we can come up with the questions for things like, "What I do for a
living", "What's your interest?", "Where might this be applicable?", "What's your
industry?" to give the responses some context?
Hal:
Yeah, I'm particularly interested in security versus non-security because we strongly
took the stance that security policy languages are different from other kinds of policy
languages. And I think we're at least opening the door to changing that with this
approach. So I'm interested to see if we can get any feedback on that or, or not.
Bill:
So we can do a draft and then at the next meeting or I can post it to the list once
we've got our candidate questions and then we can fine tune it and then spam it out
there and see what we get.
Steven:
Yeah, I was thinking that probably just having a table of the options would be one way
to go. So we, we identify just in abstract text, what the different component parts
will be. And then each line in the table is one suggestion for what we name these
things.
Bill:
I can get the questions to line up with how we wanna present it, whether we have
choices or we want to have it free.
Steven:
On the Github Cyril made a comment about the possibility of defining things using UML
diagrams and then using various tools to output XML schema, JSON schema, etc. Now, I'm
not familiar with the technology he's talking about and I suspect that in general we
probably will get a compact representation in either of those languages. So it's
probably better to have static diagrams. I'm not so convinced that automatically
generating the XML or JSON schema from that is necessarily the way to go. The
translation is a step that only ever happens once anyway, basically so we can do
it manually. It certainly gives us better alignment with version three as far as the
XML Schema is concerned.
Hal, Bill:
Agreed.
Steven:
Moving on to the further consequences of all this, we're going to need a bunch of new
documents if we're splitting things up. So we've got the Core Specification which is
abstract. We've got the XML Schema Profile. We've got a JSON Schema Profile (which may
or may not incorporate YAML). We've also talked about extracting the XPath and JSONPath
parts into separate profiles as well.
[ There was a general discussion on GitHub branch naming with the outcome being that the
TC's current work would be in a branch and whatever was considered ready for Committee
Specification would be merged with *main* so as to make consumption of the
specification easier and to address the dynamic nature of many files creating the
potential for a lot of "administrative churn". This was determined to be the best
solution for pivoting away from the previous "Editor Submission" model that was used
previously. ]
Steven:
So the option as I see them at the moment is we basically just ask for a whole new
bunch of starter documents: Core, JSON Profile, XML Profile, XPath Profile, JSONPath
Profile. We basically just pull everything back to Working Draft zero and copy what
we've got in our current CSD the Core into the new working document for Core and then
just abandon that particular document from that point on.
Bill:
Yes, I say we green field it. It's a fundamental change, structurally, everything's
changing. We're trying to make it much more modular than it was before. And there's
just no other way from the document standpoint to make that work cleanly. We're trying
to make it much more modular than it was before.
Hal:
I agree.
Steven:
So we'll need some starter documents for at least the five that I mentioned. Who wants
to take care of asking for those?
Bill:
I can do it.
Steven:
We've got three issues in GitHub about providing default values for mandatory XML
attributes: "must be present", "return policy ID list", "combined decision". I think
we're pretty much happy with them all being defaulted to False. So that's a change that
I can just incorporate whenever, just to get rid of those issues.
[ There was a discussion on combining Advice and Obligations into a single structure,
as well as simplifying Combiner parameters. ]
meeting adjourned.