Darn - I thought we had fixed all of
those enum problems. Thanks for noting it, I'll try to look into
updating the code myself to change the variable names if you don't get
there first.
Thanks!
- Shane
Luis Bruno <[EMAIL PROTECTED]> wrote
on 03/29/2006 05:38:09 PM:
> As a workaround, I added
The other obvious, although heavyweight answer, is to look into the
Eclipse EMF and XSD tools, which give a ton of information about schemas,
and support auto-generating code to create editors for a schema (although
not, perhaps, as simply editable code as your application needs). It's
worth s
(Sorry - this one got lost in my mailer)
Good comments all around (well, the few of us here!). My only suggestion
about versioning is to think about your clients - Xerces and Xalan, among
others. If they primarily can drop-in our newly refactored resolver with
no or minimal updates to the exi
-0 to including version number in the xml-apis.jar filename, unless
someone can show it will actually make sense to most people. Hmmm. But
what about including a versioned name, only for use by other projects that
already include their whole mess of dependent jars in their default
installs?
In principle, this sounds like a great idea. In practice, it really
depends if the xml-commons community is willing to actively maintain the
code. (of course, you or someone from Axis could come volunteer here)
The strength in Apache projects isn't code, it's community.
There is (or shou
Unfortunately, we don't have a current official XML-Commons release for
the xml-apis portion of the project - partly due to trying to figure out
if and how this release would need to be certified with the appropriate
TCK, since while xml-apis.jar provides the interfaces for JAXP, it does
not pr
Personally, I agree with Antonio: the distribution name should just be
xml-commons-apis-1.2.01.zip or xml-commons-external-1.2.01.zip This will
of course include the sources and docs, etc. (we can think about
splitting into src/bin distros later as well; I don't think I'll have time
for that
G. Trying to handle too many different standards at once is a
headache, I agree.
In principle I'd say we'll be shipping the version that matches the
current JAXP 1.2 TCK, since we need to pass the TCK to have an official
release. Unfortunately this sometimes means shipping potentially
co
I added brief status for commons to the newsletter.
- Shane
Sorry for the cross-post, but this issue may come up very shortly in
xml-land; perhaps one of the best places for the common XML-oriented API's
is in xml-commons? (Note: xml-commons discussion is more for the future
and tangential to any existing IP questions; please feel free to resolve
legal
Working on parts of it - but I'm going on my first family vacation in
years tonight to a place with little networking, so I doubt I can finish
it. I'm hoping David (forrest master for commons) and Norm (Mr. Resolver)
can finish up somehow, especially since they have some odd paths to
doc-relat
Unfortunately, we don't have specific version numbers for xml-apis.jar
itself. So far, I've been relying on the version number of Xalan or
Xerces, since those are the two projects who ship this most often. But we
should get in the habit of actually having a specific
xml-commons-external-x.y r
Sounds like an excellent idea. They should live under java/external/src,
since that's the root of the tree where we keep external standards files -
i.e. stuff that effectively we are getting interface definitions from
someone else.
The is exactly what xml-commons is supposed to be for - I just
Well, a couple of days of no reply isn't that big a window, especially
considering this is a fairly low-traffic list currently. You could try
asking on the general@xml.apache.org list as well to get a wider audience.
A C++ implementation certainly sounds like a good idea. I think having a
sta
Wow! New work and we haven't even been advertising lately!
It certainly sounds interesting to start with; I'd like to get a sense of
what other commons-dev watchers think before we add whole new modules.
Is this coming from existing work in the cocoon community; also are the
cocoon folks behin
Good question. Note that we now have activity in the external area
(DOM/JAXP/SAX stuff) in both the head and in the JAXP TCK-specific branch
(which must pass the Sun-supplied TCK test kit) which is what Xalan/Xerces
currently use. I presume this would only go into the head for now, until
we c
Wow! Someone on commons-dev besides me! Welcome.
<[EMAIL PROTECTED]>
> I do have a couple of changes to make to README.html
Did I miss something? 8-)
> However, can you please explain how the changes will
> get onto the website after i have done the cvs commit.
Um, it doesn't, unles
I'm hoping to put together a quick 'preview' of the xml-commons project as
an actual release, so we have a base to start discussing future commons
work and so other projects can pull a well-known and tagged set of commons
files.
For now I'll add a simple HTML doc file and build.xml file, and the '
For the purposes of the upcoming Xalan build, I plan to:
- Make a 1.0D01 release of xml-commons with an xml-apis.jar exported
- check that .jar into xml-xalan/java/bin
- change the xml-xalan/java/build.bat/.sh to put xml-apis.jar on the
classpath before calling Ant.
This way, the Xalan build will
(Arrrgggh: marc.theaimsgroup.com's archives have dropped a number of recent
xerces-j-dev posts, which is why I haven't been participating on this
thread.)
> > [EMAIL PROTECTED] wrote:
> >General comment: Factoring out the standards is a fine idea -- Xalan
also
> >did so, with its xml-apis.jar fil
Two minor notes about the recent Xerces-J release:
-> Astute code watchers will note that the relatively new xmlParserAPIs.jar
that Xerces includes DOM and SAX interfaces plus only the javax.xml.parsers
package of the JAXP interfaces. There are a number of minor differences
between the xml-common
(Apologies if this is a dup, mailer problems abound this week)
you Jeff Turner <[EMAIL PROTECTED]> wrote
[jt]>> What needs to change? Do you see something specific? This
paragraph from xml-commons/README.html:
> New modules generally shouldn't go in until at least two separate
> other
If someone points me to some simple instructions on how to be a moderator,
I'll volunteer. (I've never done it before, so...) But I don't have
apmail or whatever permissions, so someone else like Sam will need to point
moderating at me.
If return addresses matter, I should be [EMAIL PROTECTED] s
I've gone ahead and 'bent' the new code rule for xml-commons and just
checked this new 'Which' environment checking utility in without asking.
But it's so blindingly useful, and I already know that the
org.apache.xalan.xslt.EnvironmentCheck utility that this new
org.apache.env.Which utility replace
Thanks for the posting - this is definitely an important thing for the
xml.apache.org community, particularly the xml-commons community - to
review.
I hope they're counting the org.xml.sax in the same kind of area as DOM and
so on... interesting that was not listed specifically (although I haven't
Yes, I've been meaning to do exactly this, but 1) not enough time, and 2) I
always take a while setting up a project because I have to get it just
right, and I want to make sure we go the XML docs route (checkin some
format .xml docs to xdocs/ and then have them built at first just into the
static
Just seeing who's actively looking at commons-dev...
Although we don't necessarily have buy-in from all other xml projects in
how to use commons code, it seems like it might be useful to have a 1.0
release of xml-apis.jar just so that other projects who wish to refer to a
.jar file or a specific c
For those who pay attention to this stuff: I've bulk-checkedin the copies
of DOM, SAX, and JAXP standards files from the xml-commons repository into
the xml-xalan repository. While the long term plan is to always pull these
standards-based files from the xml-commons repository, we haven't quite
ta
Could one of you two evaluate this and apply it to xml-commons at your
leisure? I think this is a no-brainer to stick into Xalan this weekend
(Scott is going to apply it there). Am I missing something, or is this a
pretty obvious bug and an easy fix for other platforms?
Any quick analysis you ha
Comment the first: one particular Xalan bug was actually an easy fix, so
this is much lower priority than I thought.
you Edwin Goei <[EMAIL PROTECTED]> wrote
> So who requires compilation with JDK 1.1? What's wrong with compiling
> with Java 2 and distributing the jar files?
Comment th
Is this true? I thought we weren't going to require JDK 1.2+ quite yet.
I was about to temporarily copy the JAXP stuff into the xml-xalan tree so
we can short-term use the new code in the xalan build, but I don't want to
yank xalan developers into the 1.2+ requirement yet. (Yes, I should help
wor
31 matches
Mail list logo
