From owner-freebsd-doc@FreeBSD.ORG Sat Jun 8 17:46:06 2013 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A289069E; Sat, 8 Jun 2013 17:46:06 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 2E2DC1ADB; Sat, 8 Jun 2013 17:46:06 +0000 (UTC) Received: from alph.d.allbsd.org (p2175-ipbf701funabasi.chiba.ocn.ne.jp [122.25.209.175]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r58Hjmal030846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Jun 2013 02:45:58 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r58HjkDj060103; Sun, 9 Jun 2013 02:45:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 09 Jun 2013 02:45:43 +0900 (JST) Message-Id: <20130609.024543.2005697524919871266.hrs@allbsd.org> To: gabor@FreeBSD.org Subject: Re: RFC: Upgrading to DocBook 5.0 From: Hiroki Sato In-Reply-To: <51AF556A.40803@FreeBSD.org> References: <519FA4FE.4030305@FreeBSD.org> <20130605.211048.366435368879986578.hrs@allbsd.org> <51AF556A.40803@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jun__9_02_45_43_2013_349)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sun, 09 Jun 2013 02:45:58 +0900 (JST) X-Spam-Status: No, score=-94.5 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,RCVD_IN_PBL,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: doc@FreeBSD.org X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 17:46:06 -0000 ----Security_Multipart(Sun_Jun__9_02_45_43_2013_349)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gabor Kovesdan wrote in <51AF556A.40803@FreeBSD.org>: ga> Em 05-06-2013 14:10, Hiroki Sato escreveu: ga> > Gabor Kovesdan wrote ga> > in <519FA4FE.4030305@FreeBSD.org>: ga> > ga> > ga> username --> systemitem class="username" ga> > ga> groupname --> systemitem class="groupname" ga> > ga> hostid role="fqdn" --> systemitem class="fqdomainname" ga> > ga> hostid role="hostname" --> systemitem class="fqdomainname" ga> > ga> hostid role="domainname" --> systemitem class="fqdomainname" ga> > ga> hostid role="netmask" --> systemitem class="netmask" ga> > ga> hostid role="mac" --> systemitem class="etheraddress" ga> > ga> hostid role="ipaddr" --> systemitem class="ipaddress" ga> > ga> hostid --> systemitem ga> > ga> > Hmm, I do not like to create "a rule" to mark up both a username and ga> > a hostname by using element without attribute. Even if ga> > the rendering results are the same, they are different. Is it ga> > problem with allowing both writing s without attribute ga> > and adding attributes into them later (or at the same time)? I do ga> > not think limiting the vocabulary is useful for learning. Allowing ga> > people who are not familiar with DocBook to mark up by using ga> > only should be enough if it is really an issue. ga> Technically it is easily possible to convert them "correctly", i.e. as ga> described above, it was just my suggestion to leave out class ga> attributes. It is also possible to allow systemitem with and without ga> the class attribute specified. Yes, it is just my preference, too. ga> > ga> This is actually a type of file and the filename class attribute ga> > may ga> > ga> also be devicefile, which expresses its semantics. Again, we ga> > should ga> > ga> consider dropping the class attributes to simplify things: ga> > ga> devicename --> filename class="devicefile" ga> > ga> ga> > ga> These are not actually distinguished in formatting and the package ga> > ga> element expresses them better: ga> > ga> filename role="package" --> package ga> > ga> filename role="port" --> package ga> > ga> > package should support a role to distinguish if it is a port or a ga> > package because the linkend can be different. The following DSSSL ga> > fragment was removed in our XSLT: ga> > ga> > ---- ga> > (element filename ga> > (let* ((class (attribute-string (normalize "role")))) ga> > (cond ga> > ((equal? class "package") ga> > (let* ((urlurl "http://www.FreeBSD.org/cgi/url.cgi") ga> > (href (string-append urlurl "?ports/" ga> > (data (current-node)) ga> > "/pkg-descr"))) ga> > (create-link (list (list "HREF" href)) ($mono-seq$)))) ga> > (else ($mono-seq$))))) ga> > ---- ga> It's true that I didn't notice this distinction in the rendering. But ga> why not addding this link to both packages and ports? My personal ga> impression is that there are people, who mostly use packages and ga> others, who use ports. This preference is independent from the ga> context. If the text talks about the textproc/docproj ports but I ga> prefer dealing with packages, I will still want to install the package ga> and vice versa. In the essence, they are the same. This is why I would ga> not distinguish them. I think both can have a link, but ftp/wget and wget-1.14.tbz will have different linkends, for example. Although a single linkend like http://.../ports/ftp/wget.html can be applied to the both via XSLT, algorithms of URL generation from the markup text become different between ports and packages. Simplification of markup restricts such a possibility, I think. -- Hiroki ----Security_Multipart(Sun_Jun__9_02_45_43_2013_349)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlGzbccACgkQTyzT2CeTzy2TcwCcCWnqulYpNg498XqC+4GDQkFV UlIAoM/cmK8D6AQ5+Zrq2OCwRyYAUWlx =hLB1 -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jun__9_02_45_43_2013_349)----