Closed
Bug 98413
(xmlcatalog)
Opened 23 years ago
Closed 7 years ago
Implement XML Catalogs
Categories
(Core :: XML, enhancement)
Core
XML
Tracking
()
RESOLVED
WONTFIX
Future
People
(Reporter: hjtoi-bugzilla, Assigned: hjtoi-bugzilla)
References
()
Details
(Keywords: perf, Whiteboard: [Hixie-P3])
The XML Catalogs is an OASIS committee specification, basically an "SGML Catalog for XML". Simplified, a catalog's function is to map public identifiers to system identifiers. The specification was developed under the Entity Resolution committee: http://www.oasis-open.org/committees/entity/ The actual specification is at (Aug 6 2001): http://www.oasis-open.org/committees/entity/spec.html Currently there are at least five tools that support this specification ranging from gnome-xml to Sun's Java Resolver classes and some Perl modules. Implementing this specification would allow us to easily add support for some well-known DTDs (based on their public identifiers) by placing the DTDs locally into dtd or chrome directory (we read external DTDs if they are there). This is also a performance issue: if a match is found in the XML Catalog and we can load the DTD from a local file, we do not need to load it from the web.
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → Future
Updated•23 years ago
|
Whiteboard: [Hixie-P3]
Updated•22 years ago
|
QA Contact: petersen → rakeshmishra
Assignee | ||
Updated•22 years ago
|
Alias: xmlcatalog
Comment 1•21 years ago
|
||
xpinstall packages should be able to register new catalogs. Any idea how this could happen? The spec notes that catalogs are linked with some next-catalog entry, which would require a new catalog to modify the currently last one. That doesn't sound right. We have global and user installed packages, too.
Updated•21 years ago
|
QA Contact: rakeshmishra → ashishbhatt
Comment 2•19 years ago
|
||
Hello, I have some additional information * KDE have an OASIS XML Catalog implementation which perhaps could be used in Mozilla et al. It's written in C++ with stl-like data/container classes(the Qt/KDE libraries), synchronous file loading(due to API designs), written against a referenced counted DOM implementation(small usages of DOM 3 core), is documented, debugged, and licensed under GNU LGPL. sloccount says it's about 2500 lines of code. I can't tell whether integration work would be more than writing a stack from scratch, but it's far from impossible. The implementation can be found in: http://webcvs.kde.org/kdenonbeta/kdom/catalog/ * In relation to KDE's implementation, was a test suite brought into the light. It is quite good, and has currently 42 tests. Licensed under MIT license. It can be found at: http://webcvs.kde.org/kdenonbeta/kdom/catalog/ I'm author and maintainer of the implementation, and co-author and maintainer of the test suite, so feel free to contact me. Cheers, Frans
Updated•15 years ago
|
QA Contact: ashshbhatt → xml
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
:annevk would have been good having a short description why it is Resolution: --- → WONTFIX. As a wild guess: - 16 years ago when this issue was created, XML had all the hype attention. Now-a-days, external entities or catalog external references may expose more security risks than services anyone needs. - So gone remote XUL and high risk. No regret. Tech moves-on.
Comment 4•7 years ago
|
||
Yeah, there's basically no interest to invest further in XML-based technologies, other than moving what we already expose to the web to Rust, for added safety.
You need to log in
before you can comment on or make changes to this bug.
Description
•