| Hi everyone,
I'm sending this note as advance warning. It is likely that the Errata process will be going away; most complain that it is useless since it does not allow substantive changes to be made (i.e. most bug fixes). If there are known problems to be rectified it is much better to withdraw the OS submission and fix those now, but of course it's completely up to the TC. The current Errata process will be replaced with a Maintenance release which will most likely have the same approval path as any other Work Product.
These conversations are happening now in the Board Process Committee and it is unclear what the outcome will be or when it will go into effect. I just wanted to make sure you weren't planning on something that might not be there when you expect it.
Regards,
Mary
Mary P McRae Director, Standards Development Technical Committee Administrator Member Section Administrator OASIS: Advancing open standards for the information society twitter: @fiberartisan #oasisopen phone: 1.603.232.9090
Standards are like parachutes: they work best when they're open.
On Oct 14, 2010, at 2:36 PM, Eric Sirois wrote:
Hi Chris,
I'm not sure why the parser is complaining
about commonElementsGrp.xsd. If there are issues, it should be with
commonElementsMod.xsd. I removed references to the XML namespace
from files that did not make use of attributes within that file. Having
those there was making MSXML complain about issues as well.
Not sure why since the complaining.
I ran SCMPrint -f D:\dita1.2\doctypes\xsd1.2-url\technicalContent\xsd\map.xsd
using Xerces 2.6.0. There are no issues returned. I also ran
SAX2COUNT on the sample map.dita that points to the same map.xsd file and
it does not return any issues.
I did use the application XML Copy Editor
to validate some sample files. It uses Xerces-C to validate documents.
It looks like it uses Xerces 2.8.0.
I tried opening the same map.dita sample
in our version of Arbortext Editor. I get the following issue:
D:\dita1.2\doctypes\xsd1.2-url/base/xsd/commonElementMod.xsd
: Line: 2910 Column: 39
Could not find top level attribute:
xml:lang
I'm not sure why that error is popping
up. The commonElementMod.xsd file does have a reference to xml.xsd.
As for the rest of the issue, unfortunately,
they are bugs. We can fix those with an errata when then spec becomes
a recommendation.
Kind regards,
Eric
Eric A. Sirois
Staff Software Developer
DB2 Universal Database - Information Development
DITA XML Schema Architect and DITA Open Toolkit Developer
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Phone:(905) 413-2841
Blue
Pages (Internal)
"Transparency and accessibility requirements dictate that public information
and government
transactions avoid depending on technologies that imply or impose a specific
product or
platform on businesses or citizens" - EU on XML-based office document
formats.
All,
I’m in the process of integrating the
latest DTD and Schema changes into the copies we have in our install tree
for the next release, and I think I’ve found some bugs in the schemas.
Firstly, schema-based maps are showing
errors about not being able to find xml:space and xml:lang top-level attributes
from commonElementsGrp.xsd. I notice in the latest changes, Eric
removed the schemaLocation attribute from the import for the XML namespace.
Is there a reason it was dropped? It’s there other places
the namespace is imported (utilitiesDomain, programmingDomain, softwareDomain,
and uiDomain). Adding it back causes our Editor to stop complaining.
Also, learningMapDomain.xsd misspells ‘locktitle’
(‘loctitle’). Looks like this dates back to when it was first added in
January, so it’s not a new bug.
Finally, the learning schemas have some
class attribute bugs. The class attribute on lcLom is incorrectly
defined as “+ topic/metadata learning-d/lcLom” instead of “+ topic/metadata
learningmeta-d/lcLom”, and learningSummaryRef uses "- map/topicref
learningmap-d/learningSummaryRef " instead of "+ map/topicref
learningmap-d/learningSummaryRef " (- instead of +).
None of these problems are in the DTD versions.
I don’t know what the implications are for changing the schemas at this
point in the process, but I wanted to raise the issue.
Chris
P.S. Arbortext Editor has a Specialization
Validation tool (historically, incorrect customer specializations is one
of our major tech support headaches). It uncovered all but the first issue.
Going forward, I’m happy to volunteer to run it on future changes
as they’re made as a sanity check.
|