Bug 98413 (xmlcatalog)

Implement XML Catalogs

RESOLVED WONTFIX

Status

()

enhancement
RESOLVED WONTFIX
18 years ago
2 years ago

People

(Reporter: hjtoi-bugzilla, Assigned: hjtoi-bugzilla)

Tracking

({perf})

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(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.
Target Milestone: --- → Future
Whiteboard: [Hixie-P3]

Updated

17 years ago
QA Contact: petersen → rakeshmishra
Alias: xmlcatalog

Updated

17 years ago
Blocks: entities

Comment 1

16 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

16 years ago
QA Contact: rakeshmishra → ashishbhatt

Comment 2

14 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 
 
 
QA Contact: ashshbhatt → xml

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX

Comment 3

2 years ago
: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

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