-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default namespaces make rules unintuitive and complex #8
Comments
If an implementer upgrades their application with a new version of the library that supports this without first either reading the change log or performing some form of testing then it is their own fault. I think this would be a very welcome change both for new users looking to use the library and for more-advanced users looking to save time by always including the proper namespace everywhere. |
Jake, I appreciate the feedback. In my gut I wanted to make this the new default (because it's easier/nicer) but was worried about the edge use-case. As you pointed out, there are ways to effectively minimize the risk. I think adoption is limited enough at this point that changing default library behavior should hopefully not be a breaking change for many folks. I'll make plenty of notifications available (notes, blog, etc.) clarifying the new behavior when it goes live. I'll also do a major version change as is my policy with "API-breaking-changes" to indicate a big change so folks are more tempted to test before rolling to production. |
Another user reported the same issue today, with the example file below, the default navPoint rule looks fairly hellacious <?xml version="1.0" encoding="utf-8"?>
<ncx xmlns="http://www.daisy.org/z3986/2005/ncx/" version="2005-1"
xml:lang="zh_CN">
<navMap>
<navPoint id="ncx_newwzh_htmlfile_split_0" playOrder="1">
<navLabel>
<text>楔 子</text>
</navLabel>
<content src="newwzh_htmlfile_split_0.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_1" playOrder="2">
<navLabel>
<text>第一章 突击结婚</text>
</navLabel>
<content src="newwzh_htmlfile_split_1.html" />
<navPoint id="ncx_newwzh_htmlfile_split_2" playOrder="3">
<navLabel>
<text>一 知心搭档</text>
</navLabel>
<content src="newwzh_htmlfile_split_2.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_3" playOrder="4">
<navLabel>
<text>二 现场“选秀”</text>
</navLabel>
<content src="newwzh_htmlfile_split_3.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_4" playOrder="5">
<navLabel>
<text>三 申请结婚</text>
</navLabel>
<content src="newwzh_htmlfile_split_4.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_5" playOrder="6">
<navLabel>
<text>四 组织谈话</text>
</navLabel>
<content src="newwzh_htmlfile_split_5.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_6" playOrder="7">
<navLabel>
<text>五 首长相亲</text>
</navLabel>
<content src="newwzh_htmlfile_split_6.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_7" playOrder="8">
<navLabel>
<text>六 战前婚礼</text>
</navLabel>
<content src="newwzh_htmlfile_split_7.html" />
</navPoint>
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_8" playOrder="9">
<navLabel>
<text>第二章 祸起萧墙</text>
</navLabel>
<content src="newwzh_htmlfile_split_8.html" />
<navPoint id="ncx_newwzh_htmlfile_split_9" playOrder="10">
<navLabel>
<text>一 严家小院</text>
</navLabel>
<content src="newwzh_htmlfile_split_9.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_10" playOrder="11">
<navLabel>
<text>二 坑道圆房</text>
</navLabel>
<content src="newwzh_htmlfile_split_10.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_11" playOrder="12">
<navLabel>
<text>三 畸形之恋</text>
</navLabel>
<content src="newwzh_htmlfile_split_11.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_12" playOrder="13">
<navLabel>
<text>四 红杏出墙</text>
</navLabel>
<content src="newwzh_htmlfile_split_12.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_13" playOrder="14">
<navLabel>
<text>五 探亲疑虑</text>
</navLabel>
<content src="newwzh_htmlfile_split_13.html" />
</navPoint>
<navPoint id="ncx_newwzh_htmlfile_split_14" playOrder="15">
<navLabel>
<text>六 被迫离婚</text>
</navLabel>
<content src="newwzh_htmlfile_split_14.html" />
</navPoint>
</navPoint>
</navMap>
</ncx> |
Just got an email from a user trying to parse an Atom feed (http://feeds.feedburner.com/blogspot/hsDu?format=xml) and not getting any results for entry titles with the rule "/feed/entry/title".
Upon further investigation it looks like that feed defines "http://www.w3.org/2005/Atom" as a default namespace (xmlns arg in the root), which requires the rule actually becomes:
/[http://www.w3.org/2005/Atom]feed/[http://www.w3.org/2005/Atom]entry/[http://www.w3.org/2005/Atom]title
because all the default entries are technically defined in that namespace.
It would be nice if there was a way (either through automatic detection inside the parser) or through an explicit property that could be set to tell the parser to ignore the default namespace and treat it as a no-namespace so when the current path is stored inside the parser, no namespace is appended when it equals the default and then rules like "/feed/entry/title" would work without issue.
Might be worth considering to make this property turned on by default.
Only issue I can think of with that is that all existing literally-correct rules that are written like the one above would all start suddenly failing and would probably drive the authors nuts since they are technically correct-er-er with their pedantic rule definition.
Need to think about this more.
The text was updated successfully, but these errors were encountered: