[docbook] Re: XInclude 1.1
David Cramer da...@thingbag.net writes: Can you point me to what you based the Calabash implementation on? I based it on the simple assumption that what occurs between the parenthesis in xpath() must be an XPath expression. In XML Calabash, an XPath 2.0 expression. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | There is always some accident in http://www.oasis-open.org/docbook/ | the best of things, whether Chair, DocBook Technical Committee | thoughts or expressions or deeds. | The memorable thought, the happy | expression, the admirable deed are | only partly yours.--Henry David | Thoreau pgpc6xcBnetU4.pgp Description: PGP signature
Re: [docbook] Re: XInclude 1.1
On 01/25/2013 11:03 PM, Norman Walsh wrote: Fekete Robertfrob...@balabit.hu writes: Having recently moved to docbook 5, I also deeply miss the xpointer() scheme. How did moving to DocBook 5 change anything? It hasn't been removed From DocBook in any sense. Tools that supported it in 4 should also support it in 5, one imagines. Now that I remember, the exact problem was that I couldn't find any XML validator that handled DocBook5/relax-ng and the xpointer() scheme properly. (Currently we are using a patched version of Jing.) Robert The functionality that I sorely miss is the possibility to reference a tag using its ID, and xinclude everything that's within the referenced tag, except the tag itself: xi:include href=blah.xml xmlns:xi=http://www.w3.org/2001/XInclude; xpointer=xpointer(//note[@id='mynote']/*)/ That looks like the xpath() scheme to me. Be seeing you, norm - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
Re: [docbook] Re: XInclude 1.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2013 04:03 PM, Norman Walsh wrote: Bob Stayton b...@sagehill.net writes: This use case could be satisfied with the xpath scheme in XPointer, but I'm not finding any processors that support it, or even any information about that scheme. It's supported in XInclude in my XML Calabash processor. :-) A while back, I also looked around for information about it the xpath scheme but couldn't find any and so wasn't even sure what syntax to use. However, I wouldn't really be able to use it anyway if our XML Editor (Oxygen) doesn't support it. Without support in the editor, users would be confused by lots of spurious errors. I'd make a feature request to Oxygen, but would feel odd doing that without having a spec or some documentation to point to. Can you point me to what you based the Calabash implementation on? Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRBWHDAAoJEMHeSXG7afUhvhQH/1bCK3e/S1f+xx7VwS2MjQtG HKmO62lUDMXiljntzMvz2oaB39YxfieKRuJoFOadTYxnnx9z/xqgUwfe/1sUc710 7kAqXk5M/jq4Eg36TbE2mTJs4YpqiZFajISUgz6mZzgnzf1fs5nxpLCaXmRwzI+Y u4dbGI37gwxQ4c8t8BbViM3zLQa/BnYk3SLyNZdWswU9GbF4DmBcPirUAJs41/Fu kFWrFFKKnBKJLvA/liAbDjQG2AsLFExVL4xGaTohEzQeTfQdFYWPTk1glgJ6FEP1 CBIZwg1f93nna5VwhcTs156dV2ZrRz+1AaXsMDwrzzp4cYqJuv4yOGLyyte34L4= =chK5 -END PGP SIGNATURE- - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
[docbook] Re: XInclude 1.1
Bob Stayton b...@sagehill.net writes: There's an xpath() scheme and it's pretty widely supported, I believe. I cannot seem to find any information about the xpath() scheme in xpointer, except your earlier email mentioning that you implemented it in Calabash. It is listed on the W3C XPointer Registry, but the specification link goes to the W3C spec for XPath 2.0. I doubt the xpath() scheme supports the entire XPath 2.0 standard. Do you know where the scheme originated and who maintains it? And which processors have implemented it? I don't believe there's an independent spec for it. If you claim to support the xpath() scheme, I believe the expectation is that you will support all of XPath (1 or 2). Be seeing you, norm -- Norman Walsh n...@nwalsh.com | One must look for one thing only, http://www.oasis-open.org/docbook/ | to find many.--Cesare Pavese Chair, DocBook Technical Committee | pgprKIisdp2Tt.pgp Description: PGP signature
[docbook] Re: XInclude 1.1
Bob Stayton b...@sagehill.net writes: This use case could be satisfied with the xpath scheme in XPointer, but I'm not finding any processors that support it, or even any information about that scheme. It's supported in XInclude in my XML Calabash processor. :-) Be seeing you, norm -- Norman Walsh n...@nwalsh.com | The facts, although interesting, http://www.oasis-open.org/docbook/ | are usually irrelevant. Chair, DocBook Technical Committee | pgpwekOdc6u2O.pgp Description: PGP signature
[docbook] Re: XInclude 1.1
Fekete Robert frob...@balabit.hu writes: Having recently moved to docbook 5, I also deeply miss the xpointer() scheme. How did moving to DocBook 5 change anything? It hasn't been removed From DocBook in any sense. Tools that supported it in 4 should also support it in 5, one imagines. The functionality that I sorely miss is the possibility to reference a tag using its ID, and xinclude everything that's within the referenced tag, except the tag itself: xi:include href=blah.xml xmlns:xi=http://www.w3.org/2001/XInclude; xpointer=xpointer(//note[@id='mynote']/*)/ That looks like the xpath() scheme to me. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | The facts, although interesting, http://www.oasis-open.org/docbook/ | are usually irrelevant. Chair, DocBook Technical Committee | pgpzGeJZQ49Gm.pgp Description: PGP signature
[docbook] Re: XInclude 1.1
Alexey Neyman sti...@att.net writes: 3.1: [[[ Attributes other than those listed above may be placed on the xi:include element. Unprefixed attribute names are reserved for future versions of this specification, and must be ignored by XInclude 1.0 processors. ]]] Should it be XInclude 1.1 (current version of the spec) here? Yes, probably, thanks! Be seeing you, norm -- Norman Walsh n...@nwalsh.com | We are thinking beings, and we http://www.oasis-open.org/docbook/ | cannot exclude the intellect from Chair, DocBook Technical Committee | participating in any of our | functions.--William James pgpzLrrk3ykrb.pgp Description: PGP signature
[docbook] Re: XInclude 1.1
Hussein Shafie huss...@xmlmind.com writes: The new XInclude Working Draft: http://www.w3.org/TR/xinclude-11/ looks good. It attempts to fix some of the problems of XInclude 1.0: Thanks. However, the attribute copying feature as described in the Working Draft seems too restrictive to be really useful. Excerpts from the Working Draft: --- 4.3 Attribute Copying when processing XML ... Any namespace qualified attribute that appears on the xi:include element will be copied onto every top-level included item that is an element information item. If the element information item already has an attribute with the same qualified name, its value is changed to the value specified on the xi:include element. --- [1] Any namespace qualified attribute poses a problem as most schemas use attributes which are not namespace qualified. In practice, this makes attribute copying as described above useful only for attribute xml:id. The intent, and I'll try to clarify this in the next draft, is that you'd use additional, namespace qualified attributes to pass along information that a subsequent step would use to resolve duplicate IDs and such. There are two problems: 1. Copying non-namespace qualified attributes means that you can't pass attributes named parse and href, etc. And it means if XInclude 1.2 adds a range attribute, then that may collide with existing documents. Using namespaces avoids this problem. 2. There's no strategy for resolving ID/IDREF errors that is the single, right answer. The DocBook transclusion requirements document lists half a dozen possibilities. By using your own attributes, you can identify (to a downstream step) what policies you want to use in each XInclude case. [2] There are still duplicate ID validation errors in cases such as the following one: --- ?xml version='1.0'? document xmlns:xi=http://www.w3.org/2001/XInclude; xmlns:eg=http://example.org/namespace/example; pThis example includes a “definition” paragraph from some document twice using attribute copying./p xi:include href=src.xml xpointer=element(def)/ xi:include xml:id=def2 href=src.xml xpointer=element(def)/ I have to say, I'm not sure I ever even thought of doing this with xml:id. /document --- where src.xml is: --- document paraSome paragraph./para para xml:id=defSome phrase xml:id=ph1definition/phrase./para paraSome other paragraph./para /document --- which gives us (duplicate ID error for xml:id=ph1): Right. That's why you need a second step to do the right thing. The goal of attribute copying in XInclude 1.1 is to provide a mechanism for some downstream process to be able to know where the XInclude boundaries occurred. Today, you simply can't tell so you have no hope of fixing things. I don't know if it is possible to solve problems [1] and [2] while keeping the XInclude spec 1.1 as simple and as generic as it currently is. However, I would really like to see these problems solved elegantly because if this is the case, then may be DocBook 5.1 would not need to have its own, DocBook specific, transclusion mechanism: My goal is to build, as a separate spec, a vocabulary of extension attributes to use in, for example an XProc pipeline, to provide flavors of ID/IDREF fixup. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | All professional men are http://www.oasis-open.org/docbook/ | handicapped by not being allowed Chair, DocBook Technical Committee | to ignore things which are | useless.-- Goethe pgpMRRUjJcXq6.pgp Description: PGP signature
[docbook] Re: XInclude 1.1
Bob Stayton b...@sagehill.net writes: Hi Norm, I read through the new spec and it looks good. I have just a couple of comments. 1. The first example in C.6 uses frigid=line=2,6. Unless you are introducing a refrigerator identification system, I think that should be fragid. 8^) Thanks. Paul noticed that bug moments after the last call draft was officially published. Because that's always the way it is. I've already fixed the sources, it'll be fragid next time around :-) It also says There are four of them, but I think lines=2,6 is inclusive, so that would be five lines, no? The output example seems to include the fifth blank line that puts /pre on its own line. No, per RFC5147, I think that's lines 3, 4, 5, and 6 of the file. I think the newline is part of line 6. I'd be curious if you check RFC5147 and see if you think I'm misinterpreting it. 2. In C.7, the example of attribute copying, I would like to see a second example that replaces xml:id. I presume that works even when the xpointer is using the xml:id in the source file to fetch the content. Ok. I can add another example. Regarding xml:id fixup, this feature only applies to the top-level included element. If there are duplicate xml:ids in its descendants, then further fixup will be required after inclusion, right? It fixes all the references properties, but if you really have duplicate IDs and such, you'll need to do some post-processing to actually get the results you want. 3. This document does not address any improvements to xpointer. I still use xsltproc for its implementation of the xpointer() scheme of xpointer, but that scheme never became a standard. What is the status of using some kind of xpath syntax in xpointer? There's an xpath() scheme and it's pretty widely supported, I believe. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Society is immoral and immortal; it can http://nwalsh.com/| afford to commit any kind of folly, and | indulge in any kind of vice; it cannot | be killed, and the fragments that | survive can always laugh at the | dead.--Henry Adams pgpEefBOiMVRP.pgp Description: PGP signature
Re: [docbook] Re: XInclude 1.1
There's an xpath() scheme and it's pretty widely supported, I believe. I cannot seem to find any information about the xpath() scheme in xpointer, except your earlier email mentioning that you implemented it in Calabash. It is listed on the W3C XPointer Registry, but the specification link goes to the W3C spec for XPath 2.0. I doubt the xpath() scheme supports the entire XPath 2.0 standard. Do you know where the scheme originated and who maintains it? And which processors have implemented it? Bob Stayton Sagehill Enterprises b...@sagehill.net -- From: Norman Walsh n...@nwalsh.com Sent: Wednesday, January 23, 2013 1:25 PM To: Bob Stayton b...@sagehill.net Cc: docbook@lists.oasis-open.org Subject: [docbook] Re: XInclude 1.1 - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
Re: [docbook] Re: XInclude 1.1 Requirements
Hello, I read it carefully and hope I understood it. It looks to be able to solve many issues indeed, those we fight daily. If I understand correctly solving the duplicate IDs issue for example would be delegated to the processor though. How much likely processor developers will be to support all of this? Hearing their feedback would be particularly interesting. Thanks for this work. Camille Bgnis Grant cami...@neodoc.fr Tl: +33(0)9.54.96.99.55 - Fax: +33(0)9.59.96.99.55 http://www.neodoc.fr/ 5, rue de la Touloubre 13770 Venelles France On 02/04/2012 19:41, Norman Walsh wrote: Norman Walsh n...@nwalsh.com writes: In the course of trying to work out how best to address transclusion requirements for DocBook, some of us concluded that we should try to push this feature further up the stack. We've got concrete evidence of progress now: http://www.w3.org/TR/2012/NOTE-xinclude-11-requirements-20120214/ It would be very useful to get some review of these requirements. Naturally, we want to know about any cases where you think the proposal is inadequate, but in terms of judging interest it would be valuable to hear just that you read it, care, and think it sounds good. Be seeing you, norm
Re: [docbook] Re: XInclude 1.1 Requirements
On 5.4.2012 14:14, Camille Bégnis wrote: I read it carefully and hope I understood it. It looks to be able to solve many issues indeed, those we fight daily. If I understand correctly solving the duplicate IDs issue for example would be delegated to the processor though. How much likely processor developers will be to support all of this? Hearing their feedback would be particularly interesting. Hi, in XSLT 2.0 it is fairly easy to handle duplicates IDs (once you decide how to handle them). There is prototype implementation preceding this XInclude proposal, but processing will be very similar. http://docbook.org/docs/transclusion/#d6e362 If I recall it correctly this mechanism is transparently supported in XSLT 2.0 stylesheets. Jirka -- -- Jirka Kosek e-mail: ji...@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 -- signature.asc Description: OpenPGP digital signature
Re: [docbook] Re: XInclude 1.1 Requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/2012 03:36 PM, Jirka Kosek wrote: On 5.4.2012 14:14, Camille Bégnis wrote: I read it carefully and hope I understood it. It looks to be able to solve many issues indeed, those we fight daily. If I understand correctly solving the duplicate IDs issue for example would be delegated to the processor though. How much likely processor developers will be to support all of this? Hearing their feedback would be particularly interesting. Hi, in XSLT 2.0 it is fairly easy to handle duplicates IDs (once you decide how to handle them). There is prototype implementation preceding this XInclude proposal, but processing will be very similar. http://docbook.org/docs/transclusion/#d6e362 If I recall it correctly this mechanism is transparently supported in XSLT 2.0 stylesheets. Even with 1.0, there are ways to deal with duplicate ids. The thing you lose now if you xinclude in duplicate ids is validation of the wrapper document. The editor reports the duplicate ids while authoring or your sanity validation of the doc before building fails. So the solution has to allow for validating the document in a way that uses the desired id fixup. Norm's blog post implies that this would be done via a pipeline. David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPfhDhAAoJEMHeSXG7afUhfLcH/1BaILlWCyW+1SEgNhKe5t52 v5Db2YeBRqdj5aMKiyqNu2DimEQe8ZkO2i4HO06p/utG94pTo5A8H+1YHcmVgXxS mFCxG26eUHIqfvnhg9noh6So1Jjsf7PV42nBHM54sGhAcVX+Meoo83g9DYuqiPOh biwwa83bShQYidSz57/qUH7+wIVRWTdvcijJJ0FL1lioLSc1r/xpn9vQP2iOptPC uyqzlJFREdq/wvWW7zNNpd0GX6dKlOjpaPWG/1Afp61seF2/E+DPbOAlNfk8yOyQ zupvILKV0yAplbWZBuaO/IpeC8w6bQv1RnJ81rHO7i/qNwiyGILCpZvgPLQeNfw= =GFX1 -END PGP SIGNATURE- - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
Re: [docbook] Re: XInclude 1.1 Requirements
On 2.4.2012 19:41, Norman Walsh wrote: Norman Walsh n...@nwalsh.com writes: In the course of trying to work out how best to address transclusion requirements for DocBook, some of us concluded that we should try to push this feature further up the stack. We've got concrete evidence of progress now: http://www.w3.org/TR/2012/NOTE-xinclude-11-requirements-20120214/ It would be very useful to get some review of these requirements. Naturally, we want to know about any cases where you think the proposal is inadequate, but in terms of judging interest it would be valuable to hear just that you read it, care, and think it sounds good. Hi Norm, I read it, I care and it sounds good :-) I think that requirements, if implemented in XInclude V.next can be used to implement transclusions. However there are few issues which will need careful consideration: 1. Which attributes to copy? I tend to think that only namespaced attributes which are not in XInclude namespace should be copied. 2. Should be xml:id copied to included root element? If so, should it silently override original xml:id if present? Should there be way to obtain original xml:id? Or can this be left outside XInclude and it application will use their own attribute to override xml:id? 3. Profiling on XInclude. It should be possible to specify effectivity attributes on XInclude, of course in DocBook namespace, like: xi:include href=topic.xml db:security=private/ Of course then DocBook processing will have to cope with situations when after XInclude we will get inconsistency between local attribute and attribute augmented by XInclude: section db:security=private security=public.../section Nothing unmanageable, but it will make processing little bit more difficult and we will have to define how this will be handled for DocBook. 4. Language fixup. I hate it, probably it would be too big change to remove it from XInclude. But overall I think it was good of you to convince us to go XInclude way. Jirka -- -- Jirka Kosek e-mail: ji...@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 -- signature.asc Description: OpenPGP digital signature
[docbook] Re: XInclude 1.1 Requirements
Norman Walsh n...@nwalsh.com writes: In the course of trying to work out how best to address transclusion requirements for DocBook, some of us concluded that we should try to push this feature further up the stack. We've got concrete evidence of progress now: http://www.w3.org/TR/2012/NOTE-xinclude-11-requirements-20120214/ It would be very useful to get some review of these requirements. Naturally, we want to know about any cases where you think the proposal is inadequate, but in terms of judging interest it would be valuable to hear just that you read it, care, and think it sounds good. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | Consume less, share more. http://www.oasis-open.org/docbook/ | Chair, DocBook Technical Committee | pgp8oALOsEO8c.pgp Description: PGP signature
Re: [docbook] Re: XInclude 1.1 Requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2012 12:41 PM, Norman Walsh wrote: Norman Walsh n...@nwalsh.com writes: In the course of trying to work out how best to address transclusion requirements for DocBook, some of us concluded that we should try to push this feature further up the stack. We've got concrete evidence of progress now: http://www.w3.org/TR/2012/NOTE-xinclude-11-requirements-20120214/ It would be very useful to get some review of these requirements. Naturally, we want to know about any cases where you think the proposal is inadequate, but in terms of judging interest it would be valuable to hear just that you read it, care, and think it sounds good. Be seeing you, norm I've read it and think it sounds good as far as I understand it. I suspect the following blog entry also belongs in the References section: http://norman.walsh.name/2011/10/03/transclusion That blog entry describes what you would do with the changes to xinclude proposed, correct? David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPefpJAAoJEMHeSXG7afUhsikIAJTECvbNGjfvC1Riy2/FwMHr ln8Sx6P3xIFtlOOkG1NTx0uaE7UgsgUhZTN28fV+bBm6myMmt1Fg6SVVUwBud6nu 978W8xQWoxohWLsGpAXjFzVC88GTQ7A2ePs/NNo8+BLnMX7PW0fztBuZ2OzLuCh5 3Bbq9a7nZbJHiiFviMW1wj1FfB8r36BXQhR5Nbb5lMxrytwea9jkCndUkKDd97NW GziGjZctp6axxHiKVGervSbNVHnzcHh4Q7eqRGx3F03COOVS+53MfRgKdg52Mj4B wbRqmHXa6HbRIiflaXbSxx2xImCjWcwBcXA/2Fx7zGaHAn43nxkV9NyA7d9Nspk= =dM6c -END PGP SIGNATURE- - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
[docbook] Re: XInclude 1.1 Requirements
David Cramer da...@thingbag.net writes: While we're cracking things open, would it be possible to extend the element scheme [1] so you could do: xi:include href=foo.xml xpointer=element(someId/*)/ Short of the full xpath support that was in the xpointer() scheme, that would provide a lot of benefit for a small change. Many processors support the xpath() scheme which lets you do this, I believe. Be seeing you, norm -- Norman Walsh n...@nwalsh.com | To probe a hole we first use a http://www.oasis-open.org/docbook/ | straight stick to see how far it Chair, DocBook Technical Committee | takes us. To probe the visible | world we use the assumption that | things are simple until they prove | to be otherwise.--E. H. Gombrich pgpfWRxrlEvJK.pgp Description: PGP signature
Re: [docbook] Re: XInclude 1.1 Requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2012 06:48 AM, Norman Walsh wrote: David Cramer da...@thingbag.net writes: While we're cracking things open, would it be possible to extend the element scheme [1] so you could do: xi:include href=foo.xml xpointer=element(someId/*)/ Short of the full xpath support that was in the xpointer() scheme, that would provide a lot of benefit for a small change. Many processors support the xpath() scheme which lets you do this, I believe. That sounds like what I need, but I'm not finding much about it when I search. I've come up with this: http://www.simonstl.com/ietf/draft-stlaurent-xpath-frag-01.html When I try it in Oxygen, I can't get it to work. Jing reports that xpath1 is unsupported and Oxygen doesn't resolve it. Is there more information out there? Perhaps I'm doing it wrong. Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPRRCZAAoJEMHeSXG7afUhRk8IAIqy7dZZdGjde6c1OvHNrGrP JGGTD0ba6orwp8gApwe8ixGJZuMyb+oUkg9rZRUTcQvTZzXHlDUmIzEE9HYbCYe3 lqaS7MfrFiiNHrbxWxPSu51ZjN1B3S1hyyz00nMqXlPmAUqe9ncFS7lCd+9atjzP mNAMOl1mOYkfYwo3vfGQA38i8psEf1SEbO2oV2slyGVOuM5GxfqS50LlKOJU2fKo v5NCfe5ZcsxEv5g0lrVCarhAQaYSxEyvE2zYbv3lwsmYztoIT5V3zPAgcLaK8jM2 0ovSjne2IlYdC/D11oTHro1RRldi8j/uIS3Bu6W6kujRKywC6XxQQAL618wvEtQ= =KYAH -END PGP SIGNATURE- - To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org For additional commands, e-mail: docbook-h...@lists.oasis-open.org
