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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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


Subject: DocBook Technical Committee Meeting Minutes: 22 May 2013


> DocBook Technical Committee Meeting Minutes: 22 May 2013
> =============================================================
>
> The DocBook Technical Committee met on Wednesday, 22 May 2013 at
> 1:00pm ET for 40 minutes.
>
> The DocBook TC uses the #docbook IRC channel on
> irc.freenode.org.  The IRC channel is used for exchanging
> URIs, providing out-of-band comments, and other aspects
> of the teleconference, so please join us there if at
> all possible.
>
> Agenda
>
> 1. Roll call

Present: Norm, Loren, Jirka, Larry
Regrets: Bob, Nancy

> 2. Accepting the minutes [1] of the previous meeting.

Accepted.

> 3. Next meeting: 19 June 2013

No regrets heard.

> 4. Review of the agenda.

Accepted.

> 5. Review of open action items
>
>  a.  Norm to publish an XSD for 5.1 when it is finished.

Continued.

>  b.  Norm to follow up on OASIS mirroring the schema directory.

Continued.

Some discussion. Narrow answer: everything on the site has to go
through the 30/60 day member review process.

Norm: I don't really know what to do. I'll follow-up again with the
administrator to see what the current status of the pages is.

Jirka: If OASIS can't be flexible, maybe we have to just move all the
ancillary materials to docbook.org and only put approved standards on
the OASIS site.

Norm: Yes, I think that's one possibility. We've got the worst
situation now, where the stuff on the OASIS site is out-of-date but
looks like an attempt to have the ancillary materials there.

>  c.  Larry to try mapping slides to assembly.

Continued.

Larry: I'm having trouble getting the schema that Bob sent me work.
I'm working to get a sample from the folks who put this together over
the summer. It seems to have some unrealistic content models.

>  d.  Norm to clarify bridgehead entry in TDG to indicate
>      that bridgeheads are not numbered like sections.

Continued.

>  e.  Norm to update The Definitive Guide that the
>      behavior of nested links is undefined by the standard.

Continued.

>  f.  Norm to prevent link element nested within link element in DocBook 5.1.

Continued.

>  g.  Norm to produce a DocBook 5.1 candidate release.

Continued.

>  h.  Norm to follow up on RFE 3491860 license tag

Continued.

>  i.  Norm to add result element to DocBook 5.1 schema.

Continued.

>  j.  Dick to prepare an example of "see under" index entries.

Completed.

>  k.  Dick to fix the DocBook5 conversion stylesheet on SourceForge.

Continued.

>  l.  Bob to review Dick's fixes to the conversion stylesheet.

Continued.

>  m.  Norm to change info from "zero or one" to "zero or more"
>      in DocBook 5.1.

Continued. Norm objects.

>  n.  Jirka to prepare a proposal to support RDFa.

Completed.

Jirka found that Norm has already done it. Sent a pointer to it, it's
From 14 May.

https://github.com/docbook/docbook/blob/master/relaxng/extensions/rdfalite/rdfalite.rnc

Norm: Plan is for the committee to publish that as a schema?

ACTION: Norm to pull the rdfalite schema together as a non-normative
release candidate.

5.1 Action "m" change info from zero or one to zero or more

Norm: I object. If you can have more than one info then why not more
than one title or more than one varlistentry or more than one
listitem? Everywhere we limit the content model to a singleton, you
could argue we should allow more than one for multi-language or
profiled documents. With the added wrinkle that info is supposed to do
some merging.

... I could see the utility in producing a "multi-lingual" or
"profile" authoring schema that allows multiple choices with the
expectation that users should choose a profile and then validate
against standard DocBook. Merging is just part of a pipeline of
actions in this case.

Larry: The request was for a generic wrapper inside of info to
accommodate differences that show up between publishing a book as an
ebook or as a website or a paper version. Rather than having put
collections of elements with condition attributes on each one, they'd
asked for a wrapper.

... It seemed that allowing more than one info element and allowing
the info element to be the wrapper would be easier because they wanted
anything that can go in the info element to be in the wrapper.

... You can do this with assembly, but the request seemed to be
something that allowing more than one info element would satisfy. With
the caveat that you could shoot yourself in the foot.

Norm: Well, the processing expectation would have to be that multiple
adjacent info elements would have to be combined. I think that should
be an out-of-band process.

... I think the purpose of the schema is to define the structure of a
valid (in a technical sense) DocBook document. I don't think we want
to have multiple, sibling info elements be a valid DocBook document.

At this point in time, I think we have tools for doing pre-processing.
Use a wrapper that you delete before processing, or use multiple info
elements that you combine. But transform to DocBook proper before
validating.

Jirka: I think I agree with Norm for the reasons he outlined earlier.

Norm: The other thing is that a neutral wrapper like this is valuable
in more places and we've had requests for a generic "block" div, etc.

Loren: Isn't the customization process designed for this sort of thing?

Larry outlined some of the discussion from last month.

Larry: You could also do this with an assembly if you wanted to. I
didn't think of that last time.

Let's leave this on the agenda for next month to see what a larger
group thinks.

> 6.  OASIS website issues

Still ongoing.

> 7.  Publisher's and eLearning subcommittee reports

No report this month.

> 8.  Transclusion in DocBook

Norm summarizes: it's going through the W3C process to get XInclude
1.1 out as a Recommendation.

> 9.  DocBook 5.1 release

Norm is on the hook for CR1.

> 10.  Review of Requests for Enhancement
>
>    To browse a specific RFE, enter the URL (on one line):
>
>      http://sf.net/support/tracker.php?aid=XXXXXX
>
>    RFEs to revisit for 6.0
>      1907003  biblioid content model too broad
>
>    RFEs under discussion
>      2820947  Ability to transclude text
>      3035565  Allow sections at any level
>      3491860   license tag
>      3593209   Add see/seealso under
>      3599576   'info' wrapper element for processing titlepage elements
>      3608790   Microdata or RDFa 1.1 Lite support for schema.org
>
>   No New RFEs
>
> -----
>
> [1] http://lists.oasis-open.org/archives/docbook-tc/201304/msg00003.html

Any other business:

Jirka: The DocBook distribution includes ITS but we need to update the
schema to ITS 2.0. I need access to the new schema repository.

Norm: I'll take care of getting access for Jirka.

Some discussion of github vs. subversion for the repository.

Adjourned.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Curiosity will conquer fear even
http://www.oasis-open.org/docbook/ | more than bravery will.--James
Chair, DocBook Technical Committee | Stephens

Attachment: pgpbk7vxcTGLe.pgp
Description: PGP signature



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