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: RE: [docbook-tc] DocBook Minutes: 22 September 2010


We could also do some discussion of the sample and writeup in e-mail before the meeting.

Regards,
Larry

-----Original Message-----
From: Norman Walsh [mailto:ndw@nwalsh.com] 
Sent: Wednesday, September 22, 2010 11:33 AM
To: docbook-tc@lists.oasis-open.org
Subject: [docbook-tc] DocBook Minutes: 22 September 2010

Norman Walsh <ndw@nwalsh.com> writes:
> DocBook Technical Committee Meeting Agenda: 22 September 2010
> =============================================================
>
> Agenda

Scribe: Norm

> 1. Roll call

Present: Norm, Nancy, Larry, Paul, Jirka, Scott, Dick
Regrets: Bob

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

Accepted.

> 3. Next meeting: 20 October 2010

No regrets heard.

> 4. Review of the agenda.

Accepted.

> 5. Review of open action items
>
>  a.  Norm to develop a proposal for maintaining the DocBook websites.

Continued.

>  b.  Larry to render the current reltable example from
>      Bob and Norm with the current assembly elements for
>      comparison.

Larry couldn't find the example.

ACTION: Nancy to send some example reltables to the tc-list.

Larry's action continued. Larry and Nancy will work together on the
conversion.

>  c.  Larry to create a sample of @type in an assembly.

Completed.

>  d.  Paul to review Jirka's transclusion proposal

Completed.

[[ Actions carried over from last month ]]

ACTION: Bob to write up a short policy statement about
the use of the DocBook namespace.

ACTION: Bob to respond to the RFE 3035565.

> 6.  Publishing Subcommittee report.

Scott: Updated spec sent to Mary so hopefully they'll be posted soon.
Otherwise, I think we're done pending any new requirements coming in.

> 7.  eLearning Subcommittee report.

Scott: Time commitments and interest appear to have waned, so we'll
set this item aside until such time as interest returns.

> 8.  Reltables in modular DocBook.

Continued.

> 9.  Transclusion in DocBook.

Jirka: I sent some email summarizing open questions. We need to review
those eventually.

Paul's review starts here:

  http://lists.oasis-open.org/archives/docbook-tc/201009/msg00001.html

High level summary:

- ID fixup is hairy
  - So many options may lead to interoperability problems

- Profiling can lead to circularity as it's currently described

Paul: I wonder if XInclude with a scheme that does ID fixup might be a
better answer.

Larry: During earlier discussions of this, we discovered that there's
a lot of variability in XInclude implementations. That was part of the
motivation for putting this in DocBook.

Paul: But if you can't get people to implement XInclude interoperably,
why do we think that people will implement the DocBook alternative?

Jirka: There's also the issue of ease-of-use. The XInclude syntax is
very verbose.

Norm: I suppose if we can describe our syntax in terms of XInclude,
that might help. But I'm not sure how an XInclude scheme can handle
ID fixup.

Jirka: For ID lookup, you need additional elements in the
document to apply the various rules.

[Scribe may have missed something here]

Larry: I missed the discussion of dropping support for use case 6.
I was a little surprised because in the assembly thing we already have
a grammar attribute.

Norm: I think part of the thinking was to keep the transclusion stuff
reasonably simple.

Larry: I think that may make it harder to explain. Users are going to
see the grammar attribute in assemblies and wonder why we don't have
it here.

Norm: I think we're moving towards a world where you can't usefully
process DocBook with ordinary XML tools. To do assemblies, you need a
DocBook assembly processor. To do transclusion in the full generality
we've specified so far, you need a DocBook transclusion processor. I'm
not sure this is a bad thing, but it's different and it's causing me
some concern.

Jirka: If Paul think it's useful, I can investigate a way to map our
elements to XInclude.

Norm: I think that might be useful.

Paul: Jirka, can you remind me about your latest thought on ID fixup.

Jirka: If it looks too complicated to have all the options, we could
have two conformance levels: one that's fixed and simple, and another
that's got more options. We can then let the market decide what level
gets supported.

ACTION: Jirka to investigate transclusion-to-XInclude mapping.

> 10.  Review of Requests for Enhancement
>
>    To browse a specific RFE, enter the URL (on one line):
>
>      http://sourceforge.net/tracker/index.php?func=detail&;;
>      group_id=21935&atid=384107&aid=XXXX
>
>    Nothing new this month.

Consequently, no discussion.

> [1] http://lists.oasis-open.org/archives/docbook-tc/201008/msg00008.html

Any other business?

Larry: I'd like some feedback on the @type assembly proposal.

Let's put discussion of the help example on the agenda for October.

Adjourned.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Wink at small faults; for thou has
http://www.oasis-open.org/docbook/ | great ones.--Thomas Fuller (II)
Chair, DocBook Technical Committee |


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