OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Editorial actions completed and pending


Gents,

now it is dinner time here, and I shortly wanted to report what is already on the "private" plate a.k.a. editor revision of the document
what will end up in WD06 before tomorrow's meeting:

* added boilerplate from fresher workproducts like IPR mode and the
  lower/upper case extra rendition of the RFC2199 ...

* corrected the member formatted regions listing the sub-components of
  the components

* removed color marked TODO labels with the (understood) planned
  content)

* corrected nirvana links that word or we had simply lost

* tagged all sub-component and element tags I did not miss with data
  type word style

* Added marks for components and sub-components to build a two level
  index in appendix B

* Edited the Acknowledgements list in Appendix A to really only contain
  those, that contributed - now nice and cosy

* Swapped the sequence of XML syntax and JSON syntax sub-sections per
  component as ruled by alphabetical ordering and "direction future" :-)
  ... and also indicatedin the explanatory initial sections, so,
  JSON first, XML second

* Removed the idiosyncratic "Semantics" sub-section per component, as
  hopefully the semantics are shared across the syntaxes ;-)
  The only last man standing to maintain a subsection so we can refer
  to in isolation was laughed away during a short coffee break.
  YMMV, but I think this is far more clear, as we only have two ways
  to actually "speak" DSS ... so two subsections per component are
  kind of principle of least surprise

* Added a minimal overlapping prefix to the syntax sub-sections, so
  that linkage does not overheat the brais of readers, thus instead
  of cf. section 42.2.1 JSON Synatx, it now reads cf. section 42.2.1
  FooBarBaz -- JSON Syntax

* Removed the general index as we are trying to align on calendar with
  ETSI roadmap, and a general index really takes more time and costs
  the time we should spend on factual discussions / enhancements I think

* Added a few Non-normative notes as to the sans serif problems with
  terms like OptionlInputs and friends where the lowercase L and the
  upper case I kill my eyes (at least in revising pre-publication mode)

* I killed the content of an envisioned Terms and whatever section by
  claiming we did not bend any terms compared where they are usually
  meant to stand for.

* I added the brittle reference to Chipgateway profile as kindly
  suggested by Detlef - but, we should expect technical comments
  as to not cite such in development documents ...

* Detlef also helped me decide to simply replace the 1.0 of result
  ids into 2.0

* Made some headings unique (General Processing as a sample)
  and tried to either keep the signing part unadorned by appending some
  verify notion to the verify pendant or added Timestamp (where I
  detected that timestamping is the processing topic

* Changed some headings to title case

* Corrected quite some missing commas (after So, ... and friens) and
  removed even more that had been prepended to ands in listings

* Added in one case a sentence that explaind why there is no specific
  sub-component list but only the inherited one

* Made service to the reader more explicit (introduction of the JSON
  listings)

* I did not add Example enumerations, as the examples are nicely
  aligned and matched one-to-one to the syntax sections

* Repaired some already present normative statement markers

* Made the font in the ResultMinors table on the right smaller so the
  codes appear on one line and to help with the horizontal space needs
  split the "name" of those in the left column (readability counts)

* Edited all listings to have the Word SHIFT-ENTER in all but the last
  lines (or where a page break was rquired due to the length of the
  listing.

* Shifted most XML (and even some JSON) line ingredients that exceeded
  the line length where possible, so the elements or containers stand
  more orderly out

* Made fallback snapshots after every sweep (30 minutes) to better
  survive the typical 150 pages highly connected and self-referenced
  word document disaster that might come along now and then

* The table of contents is now constrained to level 4 and reads
  meaningfully (IMO)


What is still missing?

1. I will clean up all MAY SHOULD SHALL MUST statements and will
   tag these as planned.

2. Most MAY will disappear and be repaced with SHALL statements, as
   these are (a) detectable (b) have often zero or more as cardinality
   and (c) do not really match the often problematic situation that MAY
   was designed for to handle in the first place

3. Will try to replace all MUST with SHALL (and the NOT variants)
   where the document is verifiable against the statement.
   In the rare case, wher there is an outer mandatory condition
   requester or responder cannot beinfluence but simply can only
   react upon, I will leave the MUST

4. repair the conformance section (was until now a TODO kind of
   XML to JSON copy.

5. construct a PDF to see if the main navigational elements work also
   in that mandatory format and so that we know, TC admin wlll have
   no trouble building the artefacts in PDF and HTML

5. publish in kavi as WD06 so we can talk about it during tomorrow's
   meeting

Please maybe could someone take a look if we really have these case
varations in our vocabulary (as kindly requested in one of my mails to this mailing list sent a few hours ago)?
Thanks


All the best,
Stefan


/Stefan


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]