Time: 2:30 PM EST
Zoom:
Zoom Link:
http://tinyurl.com/48n4yrzs Meeting ID: 850 9753 8468
Minutes for 7 November 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 10 October, 2024 TC meeting
https://groups.oasis-open.org/discussion/minutes-10-october-2024-tc-meeting Vote: Approved unanimously.
II. Administrivia
GitHub “cc” to List update status
Bill:
Oasis has a consultant continuing to work on this.
III. Issues
Hal:
I suggest we start with the issues on GitHub.
Steven:
Bill and I worked out a way to produce indented paragraphs that look nice. It's a
rather clunky way of getting it to work properly, without having to use bullet points.
I would like to propose to just continue down that path, using our new funky technique
unless something weird shows up.
Bill:
Agree, that is in line with what we were trying to accomplish and it makes more sense
in the documents where bullets are not needed/are confusing.
Steven:
I closed a few minor issues there about default false values for some XML attributes.
They were not controversial. So I just went ahead and did them.
Steven:
We still have an open question about what we're going to call this stuff, per the
comment Bill made since the last meeting that we need to know what docs names we are
asking for. Now, we could potentially start splitting things even without having the
starter documents. We just store them in GitHub. No big deal. So they wouldn't have
that the proper boilerplate around them. But at least we could start shuffling code
into the right locations and then just patch that into a starter document when we
finally know what the right names of these things are going to be.
Bill:
I think that makes sense too because as we go through the process that will it help us
refine what we think they should be called.
Steven:
I think that would be the case as well. Yeah, we get a better idea of what the document
should be and then what they would be called as a consequence of that. So it's good to
me. There was a question. I think we covered in the last meeting about how we arrange
GitHub for the various starter documents that we're going to have. So at the moment,
we've got one branch that's set up for the what used to be the Core spec, which will
be the abstract Core spec in the future. I'm thinking that we don't really want a
separate branch for each document because that's just a pain to manage, especially if
you're shifting text from one to another and have to coordinate the different branches.
So we should probably bring everything back onto the main branch and then just create a
subfolder for each one of the starter documents that we intend to create. I mean, we're
waiting on deciding what the names are before we create the actual starter documents,
we just lump everything together in the same folder. It only really matters when we get
to the point where we want to submit this to TC Admin to process it. They need it in a
particular arrangement with subfolder for images, a subfolder for CSS and that sort of
thing.
Bill:
Agreed, because I have a feeling whatever we decide we're going to be wrong by at least
a little bit.
Steven:
Yeah, for sure. Okay, so I'll make another proposal to just merge everything back on
the main line and basically when we start ripping things out and separating things into
the separate documents, we just lump them all together in the same folder there on the
main line and worry about it later when we've got starter documents.
Hal:
Yep, sounds good.
Steven:
As to things we haven't done yet, I mentioned in last meeting that I was taking the
approach of finding all the things where we can reduce the current Core. I'm getting
rid of the stuff we're not going to use so that when we do split things out and have to
abstract stuff, there's less stuff to abstract. We're not abstracting stuff that we're
going to throw away. So basically reduce everything as much as possible first and then
we worry about adding the new functionality that we've decided we want to add.
Steven:
So in that vein, one of the things that we can reduce is the combiner parameters. So
I've suggested that we get rid of all the combiner parameters except for the pure
combiner parameters, joining rule and policy combiner parameters, which are basically
the same structure, and use a combiner parameter to say what rule or policy they apply
to. We don't need separate constructs for rules or policies. There's a variety of
things we can do about how we deal with assigning those parameters to a rule or
assigning those parameters to a specific policy.
[ discussion on options ]
Steven:
So I suggest that we get rid of all the combined parameters except for the core,
reserving a couple of names for parameters to take the roles of the other structures
that we're throwing out and keep those as loose as possible. That will reduce a bit of
the XML and make things a little bit simpler.
Steven:
I think one of the other things that we were looking at to simplify things was
combining advice and obligations into a common structure. So I propose to do that too
before we start separating things.
[ discussion on processing documents manually vs automated fashion, consensus being that
low frequency of changes and the desire to make the syntax as concise as possible was
likely the best approach for the initial abstractions ]
Steven:
That reminds me of the namespace: One of the things that really annoyed me about
version three was the fact that each working draft had a new XML namespace. So until
such time as the specification was finally approved, we didn't actually have a stable
namespace for this stuff. Since that really annoyed me, I decided that for the XML
schema, we should just go with what we expect the final namespace to be. And it's just
up to implementers. If they implement an earlier version, they have to bring it up to
date with the final version. And not conforming until they do. And means that if you
implement an earlier version, the XML schema is not going to quite match someone who
implements to a later version, but ultimately everybody should be going to the final
approved version. Basically, if you implement to an interim specification, you have an
obligation to update that to the final specification when it's done.
meeting adjourned.