Sandra Sendra | 1 Dec 22:44 2010
Picon

2nd CfP: SOTICS 2011 || July 17-22, 2011 - Bournemouth, UK


INVITATION:

=================
Please consider to contribute to and/or forward to the appropriate groups the following opportunity to
submit and publish original scientific results.
=================

============== SOTICS 2011 | Call for Papers ===============

CALL FOR PAPERS, TUTORIALS, PANELS

SOTICS 2011: The First International Conference on Social Eco-Informatics
July 17-22, 2011 - Bournemouth, UK

General page: http://www.iaria.org/conferences2011/SOTICS11.html
Call for Papers: http://www.iaria.org/conferences2011/CfPSOTICS11.html

Submission deadline: March 1, 2011

Technical Co-Sponsors:
- The Bournemouth & Poole College
- Bournemouth University
Sponsored by IARIA, www.iaria.org

Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org

Please note the Poster Forum and Work in Progress options.

The topics suggested by the conference can be discussed in term of concepts, state of the art, research,
(Continue reading)

rob.cavicchio | 2 Dec 01:53 2010

purpose of "label" attribute

I'm looking for some clarification on the intended purpose of the "label" attribute on <book>, <chapter>, <section>, <appendix>, etc.

 

The documentation states: "Specifies an identifying string for presentation purposes".

 

I find this description to be wanting. The section title is "an identifying string". I presume that the "label" attribute value is not intended to replace the title, but to be prepended, appended, or otherwise made to appear in a context that associates it with the section (something like "Section 1-1:"). But the wording is so vague that I can't be sure of that.

 

 

*************************
Rob Cavicchio
Principal Technical Writer & Information Architect
EMC Captiva

Information Intelligence Group
EMC Corporation
3721 Valley Centre Drive, Ste 200

San Diego, CA 92130

P: (858) 320-1208
F: (858) 320-1010
E: rob.cavicchio <at> emc.com

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.

Bob Stayton | 2 Dec 23:31 2010
Picon

Re: purpose of "label" attribute

Hi Rob,
As far as the DocBook XSL stylesheets go, the <at> label attribute is treated as a manual override for the generated *number* for a section, table, figure, etc.   It is just the number part, as in "1-1".
 
Bob Stayton
Sagehill Enterprises
bobs <at> sagehill.net
 
 
----- Original Message -----
Sent: Wednesday, December 01, 2010 4:53 PM
Subject: [docbook] purpose of "label" attribute

I'm looking for some clarification on the intended purpose of the "label" attribute on <book>, <chapter>, <section>, <appendix>, etc.

 

The documentation states: "Specifies an identifying string for presentation purposes".

 

I find this description to be wanting. The section title is "an identifying string". I presume that the "label" attribute value is not intended to replace the title, but to be prepended, appended, or otherwise made to appear in a context that associates it with the section (something like "Section 1-1:"). But the wording is so vague that I can't be sure of that.

 

 

*************************
Rob Cavicchio
Principal Technical Writer & Information Architect
EMC Captiva

Information Intelligence Group
EMC Corporation
3721 Valley Centre Drive, Ste 200

San Diego, CA 92130

P: (858) 320-1208
F: (858) 320-1010
E: rob.cavicchio <at> emc.com

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.

Bob Stayton | 14 Dec 17:53 2010
Picon

DocBook Technical Committee Meeting Agenda: 15 December 2010

DocBook Technical Committee Meeting Agenda: 15 December 2010
=============================================================

The DocBook Technical Committee will meet on Wednesday, 15 December 2010 at
01:00p EST (10:00a PST, 17:00GMT, 18:00BST, 19:00CEST, 02:00JST+,
022:30p India+) for 90 minutes.

Attendance at teleconferences is restricted to members
(and prospective members) of the committee.

This is the phone number for Wednesday's DocBook TC call:

Phone: +1-719-387-5556
 Code: 902213

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
2. Accepting the minutes [1] of the previous meeting.
3. Next meeting: 19 Januaray 2011
4. Review of the agenda.
5. Review of open action items

  a.  Norm to develop a proposal for maintaining the DocBook websites.

  b.  Norm to publish an online version of DocBook 5.0 doc.

  c.  Jirka to post the transclusion spec to docbook.org.

  d.  Norm to add namespace usage policy to the official docs.

  e.  Larry to create a fresh proposal for linking within assembly.

6.  Publishing Subcommittee report.

8.  Linking in assembly.

9.  Transclusion in DocBook.

Please see Jirka's updated requirements [2] and proposal [3]

10.  Decision about Larry's help example in assembly and  <at> type proposal. 

11.  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

    RFEs to revisit for 6.0
      1907003  biblioid content model too broad  

    RFEs to be considered 
      1679665  Add better support for modular documentation  
      2820190  add a topic element  
      2820947  Ability to transclude text 
      3035565  Allow sections at any level  
      3107140  aconym expansion inline 

-----

[1] http://lists.oasis-open.org/archives/docbook-tc/201011/msg00024.html
[2] http://docbook.org/docs/transclusion-requirements/
[3] http://docbook.org/docs/transclusion/

Bob Stayton
Sagehill Enterprises
bobs <at> sagehill.net
Jirka Kosek | 15 Dec 19:29 2010
Picon

Feedback on DocBook Transclusion proposal

Hi,

during last few months DocBook TC spent serious time discussing and
working on solution for the following RFE (Ability to transclude text):

http://sourceforge.net/tracker/?func=detail&aid=2820947&group_id=21935&atid=384107

As a part of this process we gathered set of requirements for
transclusion mechanism which is available at:

http://docbook.org/docs/transclusion-requirements/

Also DocBook TC created proposal which tries to resolve problems
mentioned in the original RFE together with some additional requirements
that appeared along the way:

http://docbook.org/docs/transclusion/

At this stage DocBook TC is looking forward for feedback from DocBook
users and from implementers of DocBook tools. Our concern is that
although some proposed features are very useful they may be too complex
to gain broad adoption between implementers.

Any comments and feedback are more then welcomed. Please direct it
directly to this mailing list (docbook <at> lists.oasis-open.org).

Thanks in advance,

			Jirka Kosek
			on behalf of DocBook TC

--

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka <at> kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Bob Stayton | 16 Dec 18:36 2010
Picon

DocBook Technical Committee Meeting Minutes: 15 December 2010

DocBook Technical Committee Meeting Minutes: 15 December 2010
=============================================================

The DocBook Technical Committee met on Wednesday, 15 December 2010 at
01:00p EST (10:00a PST, 17:00GMT, 18:00BST, 19:00CEST, 02:00JST+,
022:30p India+).

1. Roll call

Present:
Paul Grosso, Dick Hamilton, Nancy Harrison, Scott Hudson,
Gershon Joseph, Jirka Kosek, Larry Rowland, Bob Stayton, Norm Walsh

Absent:

2. Accepted the minutes [1] of the previous meeting.

3. Next meeting: 19 Januaray 2011

4. Review of the agenda.

No new items.

5. Review of open action items

  a.  Norm to develop a proposal for maintaining the DocBook websites.
  CONTINUE

  b.  Norm to publish an online version of DocBook 5.0 doc.
  CONTINUE

  c.  Jirka to post the transclusion spec to docbook.org.
  COMPLETED

  d.  Norm to add namespace usage policy to the official docs.
  CONTINUE

  e.  Larry to create a fresh proposal for linking within assembly.
  COMPLETED

6.  Publishing Subcommittee report.

No further developments, awaiting RFEs.

8.  Linking in assembly.

Postponed until next meeting to digest Larry's latest proposal. [4]

9.  Transclusion in DocBook.

Jirka's updated requirements [2] and proposal [3] have been posted
to docbook.org.

ACTION: Jirka to ask the mailing list for feedback on the
transclusion proposal.

10.  Decision about Larry's help example in assembly and  <at> type proposal. 

Postponed until next meeting.

11.  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

    RFEs to revisit for 6.0
      1907003  biblioid content model too broad  

    RFEs to be considered 
      1679665  Add better support for modular documentation  
      2820190  add a topic element  
      2820947  Ability to transclude text 
      3035565  Allow sections at any level  

      3107140  aconym expansion inline 

Members felt there are already mechanisms to support 
acronyms. 

ACTION: Norm to respond to RFE.

-----

[1] http://lists.oasis-open.org/archives/docbook-tc/201011/msg00024.html
[2] http://docbook.org/docs/transclusion-requirements/
[3] http://docbook.org/docs/transclusion/
[4] http://lists.oasis-open.org/archives/docbook-tc/201012/msg00007.html

Bob Stayton
Sagehill Enterprises
bobs <at> sagehill.net
Dave Pawson | 16 Dec 19:55 2010
Picon

Re: DocBook Technical Committee Meeting Minutes: 15 December 2010

On Thu, 16 Dec 2010 09:36:28 -0800
"Bob Stayton" <bobs <at> sagehill.net> wrote:

>       3107140  aconym expansion inline 
> 
> Members felt there are already mechanisms to support 
> acronyms. 
> 
> ACTION: Norm to respond to RFE.

He did
"We talked about this on the call today. It seems that there are two
existing approaches that would work. First, you could put the acronyms
in a glossary, point to the glossary entries, and get the expansions
from there. If you wanted a one-off entry without all the glossary
machinery, you could use alt for this purpose.

If neither of those approaches satisfies your use case, could you
provide a little more detail for us?"

I've not argued that the acronym expansion could be in the glossary.
My complaint is that I can't expand it inline.
  I've no idea about the Chicago manual of style, but in English I
was always told to expand an acroym inline, on first use, thereafter
using the abbreviated form. E.g laser (light amplification by
stimulated emission of radiation), .... laser is ....

As with sighted people, a blind user shouldn't have to hike over to the
glossary to get that expansion if the author wants to use good English
practices.

Is that sufficient Norm?

-- 

regards 

--

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
Dave Pawson | 16 Dec 20:01 2010
Picon

Re: Feedback on DocBook Transclusion proposal

On Wed, 15 Dec 2010 19:29:34 +0100
Jirka Kosek <jirka <at> kosek.cz> wrote:

> Hi,
> 
> during last few months DocBook TC spent serious time discussing and
> working on solution for the following RFE (Ability to transclude
> text):
> 
> http://sourceforge.net/tracker/?func=detail&aid=2820947&group_id=21935&atid=384107
> 
> As a part of this process we gathered set of requirements for
> transclusion mechanism which is available at:
> 
> http://docbook.org/docs/transclusion-requirements/
> 
> Also DocBook TC created proposal which tries to resolve problems
> mentioned in the original RFE together with some additional
> requirements that appeared along the way:
> 
> http://docbook.org/docs/transclusion/
> 
> At this stage DocBook TC is looking forward for feedback from DocBook
> users and from implementers of DocBook tools.

Reading the requirements and Jirkas response, I was all in favour. 

Then from Norms blog I read
http://norman.walsh.name//2010/12/15/transclusion
"Will vendors implement it? "

I had thought that this was implementable using docbook stylesheets?
is that the case? If not, has implementation been considered?
If not then perhaps Norm is right with his other concern

"My other concern is more vague. This feels like something more general
than DocBook, it seems like something that other schemas might want to
reuse, so I wonder if it belongs in DocBook specifically. I suppose if
authors want it and vendors will implement it, we can let other folks
copy it."

I agree about its complexity, perhaps a W3C attitude of 'show me an
implementation then I'll give it a mark of approval' might be
appropriate? I.e. if it proves to be too complex we might need to look
for an alternative?

-- 

regards 

--

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
Jirka Kosek | 16 Dec 20:29 2010
Picon

Re: Feedback on DocBook Transclusion proposal

Dave Pawson wrote:

> Then from Norms blog I read
> http://norman.walsh.name//2010/12/15/transclusion
> "Will vendors implement it? "
> 
> I had thought that this was implementable using docbook stylesheets?
> is that the case? 

Yes, it is fairly easy to implement transclusion in XSLT 2.0. Proposal
shows proof of concept implementations that supports almost all of
proposal except of interaction of transclusions and profiling.

> If not, has implementation been considered?

The more work will be to implement this in XML editors. I think it is
implementable, the question is whether tool vendors would like to spend
money on developing this features. Remember they already have to support
entities, XIncludes and DITA conref.

> "My other concern is more vague. This feels like something more general
> than DocBook, it seems like something that other schemas might want to
> reuse, so I wonder if it belongs in DocBook specifically. I suppose if
> authors want it and vendors will implement it, we can let other folks
> copy it."
>
> I agree about its complexity, perhaps a W3C attitude of 'show me an
> implementation then I'll give it a mark of approval' might be
> appropriate? I.e. if it proves to be too complex we might need to look
> for an alternative?

Processing complexity is in handling duplicate IDs in repeatedly
inserted content and links to such IDs.

Of course it would be better to develop and use some more generic
approach then to develop something specific to DocBook. The problem is
that solution has to know which attributes are of ID/IDREF types -- it
is hard to do this without schema introspection. Also DocBook specific
mechanism will always nicely fit into language then some generic
vocabulary (compare with XInclude or XLink for example).

				Jirka

--

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka <at> kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Dave Pawson | 16 Dec 20:55 2010
Picon

Re: Feedback on DocBook Transclusion proposal

On Thu, 16 Dec 2010 20:29:19 +0100
Jirka Kosek <jirka <at> kosek.cz> wrote:

> > If not, has implementation been considered?
> 
> The more work will be to implement this in XML editors. I think it is
> implementable, the question is whether tool vendors would like to
> spend money on developing this features. Remember they already have
> to support entities, XIncludes and DITA conref.

To be quite honest, I wouldn't expect them to implement it. 
Same with xInclude.

> 
> > "My other concern is more vague. This feels like something more
> > general than DocBook, it seems like something that other schemas
> > might want to reuse, so I wonder if it belongs in DocBook
> > specifically. I suppose if authors want it and vendors will
> > implement it, we can let other folks copy it."
> >
> > I agree about its complexity, perhaps a W3C attitude of 'show me an
> > implementation then I'll give it a mark of approval' might be
> > appropriate? I.e. if it proves to be too complex we might need to
> > look for an alternative?
> 
> Processing complexity is in handling duplicate IDs in repeatedly
> inserted content and links to such IDs.

Understandable. I think my 'can it be *fully* implemented' 
is a fair question? 

> 
> Of course it would be better to develop and use some more generic
> approach then to develop something specific to DocBook. The problem is
> that solution has to know which attributes are of ID/IDREF types -- it
> is hard to do this without schema introspection. Also DocBook specific
> mechanism will always nicely fit into language then some generic
> vocabulary (compare with XInclude or XLink for example).

Which puts it nicely between the two positions? Docbook only
or generic and even harder?

My initial reaction is to restrict it to docbook,
If implemented, and if it works well there, then perhaps look for wider
adoption?

regards 

-- 

regards 

--

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Gmane