You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Andy Clark <an...@apache.org> on 2002/08/16 06:10:33 UTC
Another XNI Change Proposal
Speaking of XNI changes, I would like to propose another
change to the Xerces Native Interface...
I have now written a number of my own parser configurations
with custom parser components (e.g. NekoHTML). And I keep
running into the same problem again and again: even though
the parser configuration can query the settings that each
component supports, it has no way to know what the correct
default value should be.
Therefore, I propose adding the following methods to the
org.apache.xerces.xni.parser.XMLComponent interface:
/**
* Returns the default state for a feature, or null if this
* component does not want to report a default value for this
* feature.
*/
public Boolean getFeatureDefault(String featureId);
/**
* Returns the default state for a property, or null if this
* component does not want to report a default value for this
* property.
*/
public Object getPropertyDefault(String propertyId);
The one thing you might immediately question is my use
of a Boolean object instead of the boolean primitive. I
use this so that the component can state that it doesn't
care what the default value should be. This would be
used in situations where the component may recognize and
use a setting common to the parser configuration and/or
other components, but where it doesn't care what the
default is.
And in fact, only the component that "introduces" the
setting should set its default value. For example, both
"validation" and "namespaces" are system wide settings
and the parser configuration sets the default value. A
lot of the components use these values but will take
whatever default value has been established.
What do you think? Can we roll this change into the
codebase for Xerces 2.1.0?
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Next Xerces Release [was Re: Another XNI Change Proposal]
Posted by Andy Clark <an...@apache.org>.
Elena Litani wrote:
> I've looked at your proposal and it looks good to me. So here is my +1
> to put it into next Xerces release.
>
> The only catch is -- we plan to release Xerces next Wednesday..
In which file in CVS was this mentioned? ;)
> Do you have enough time to implement your changes?
I believe so. If you are releasing on Wednesday, what
is the deadline for changes? I'll try to put aside some
time tomorrow to incorporate the necessary changes.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Next Xerces Release [was Re: Another XNI Change Proposal]
Posted by Andy Clark <an...@apache.org>.
Joseph Kesselman wrote:
> But, as you note, this value is not a boolean value. It's tristate. By
> switching to Boolean you're already taking a step away from that simple
> view.
I don't think it's a step away.
In my work writing other parser configurations,
I've found that I need a method like this for my
components. It makes it a lot easier to mix and
match components among various configurations
without requiring the configuration to somehow
know what default values to use for settings
recognized by the various components.
For what this method (getFeatureDefault) is
intended for, you actually need a tristate value:
true, false, and null. So I think the Boolean
object is the natural choice.
*And* when the component wants to supply a default
value, it maps nicely back to the primitive boolean.
I think changing this to any other enumeration,
whether it be ints or some enum class is a bad idea.
> If you really want to stick with booleans it could be done by
> "piggybacking" two features, so you've got two bits to work with.
I don't think this is a good idea -- look at the
whole "namespaces/namespace-prefixes" confusion
for an example. And besides... this does me no
good for what this method is designed to do, which
is to return a preferred default state for a
feature recognized by that component.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Next Xerces Release [was Re: Another XNI Change Proposal]
Posted by Joseph Kesselman <ke...@us.ibm.com>.
On Saturday, 09/21/2002 at 04:30 ZE9, Andy Clark <an...@apache.org> wrote:
> And features are booleans.
But, as you note, this value is not a boolean value. It's tristate. By
switching to Boolean you're already taking a step away from that simple
view.
If you really want to stick with booleans it could be done by
"piggybacking" two features, so you've got two bits to work with.
> > In internal methods/values, Boolean-and-null for a tristate value
wouldn't
> > bother me. In an API, it feels like an accident waiting to happen.
> This is the Xerces *Native* Interface, by the way.
I'm aware of that. XNI is still an API you're expecting folks to code
against; witness NEKO and revalidaton.
> And I disagree with your assessment that this is an
> accident waiting to happen. :)
We agree that we disagree, then. <grin/> That's fine; thesis plus
antithesis yield synthesis.
______________________________________
Joe Kesselman / IBM Research
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Next Xerces Release [was Re: Another XNI Change Proposal]
Posted by Andy Clark <an...@apache.org>.
Joseph Kesselman wrote:
> And frankly, I'm not convinced that Boolean.TRUE/FALSE/null is really more
> legible than yourownclass.YES/.NO/.UNKNOWN. The resulting code doesn't
> look a heck of a lot different.
In terms of legibility, it's probably the same. But
we have to think about what this represents here --
a feature state. And features are booleans. That's
the way they were defined in SAX2 and it's been
that way ever since. I think switching to something
other than a boolean/Boolean would confuse users.
> In internal methods/values, Boolean-and-null for a tristate value wouldn't
> bother me. In an API, it feels like an accident waiting to happen.
This is the Xerces *Native* Interface, by the way.
And I disagree with your assessment that this is an
accident waiting to happen. :)
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Next Xerces Release [was Re: Another XNI Change Proposal]
Posted by Joseph Kesselman <ke...@us.ibm.com>.
On Saturday, 09/21/2002 at 03:01 ZE9, Andy Clark <an...@apache.org> wrote:
> >>>The one thing you might immediately question is my use
> >>>of a Boolean object instead of the boolean primitive.
> > I do so question. An integer with static-final mnemonic values is
probably
> > more efficient, and (I think) no less clear.
>
> Yuck. ;) Java has a boolean primitive
But as you just pointed out, you can't use it to represent a tristate
value. You have to switch to a Boolean object, which is not quite a
primitive.
Doing so gets you into the == versus .equals() game, if anyone is
incautious about the difference between Boolean(true) and Boolean.TRUE. It
also buys you some heap churn and performance loss if you aren't
consistant in using the latter (which, admittedly, can be managed).
And frankly, I'm not convinced that Boolean.TRUE/FALSE/null is really more
legible than yourownclass.YES/.NO/.UNKNOWN. The resulting code doesn't
look a heck of a lot different.
In internal methods/values, Boolean-and-null for a tristate value wouldn't
bother me. In an API, it feels like an accident waiting to happen.
______________________________________
Joe Kesselman / IBM Research
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Next Xerces Release [was Re: Another XNI Change Proposal]
Posted by Andy Clark <an...@apache.org>.
Joseph Kesselman wrote:
>>Andy Clark wrote:
>>>The one thing you might immediately question is my use
>>>of a Boolean object instead of the boolean primitive.
>
> I do so question. An integer with static-final mnemonic values is probably
> more efficient, and (I think) no less clear.
Yuck. ;) Java has a boolean primitive and I think
that it's *more* clear to use it than switch to an
integer. Especially since the setFeature method
takes a boolean as a parameter.
The only problem with the boolean (little 'b') type
is that there is no way to return "don't care" or
"no value". However, using the Boolean (big 'b')
object allows this distinction.
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: Next Xerces Release [was Re: Another XNI Change Proposal]
Posted by Joseph Kesselman <ke...@us.ibm.com>.
> Andy Clark wrote:
> > The one thing you might immediately question is my use
> > of a Boolean object instead of the boolean primitive.
I do so question. An integer with static-final mnemonic values is probably
more efficient, and (I think) no less clear.
______________________________________
Joe Kesselman / IBM Research
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Next Xerces Release [was Re: Another XNI Change Proposal]
Posted by Elena Litani <el...@ca.ibm.com>.
Hi Andy,
I've looked at your proposal and it looks good to me. So here is my +1
to put it into next Xerces release.
The only catch is -- we plan to release Xerces next Wednesday..
Do you have enough time to implement your changes?
Sorry for a short notice...
--
Elena Litani / IBM Toronto
Andy Clark wrote:
> Therefore, I propose adding the following methods to the
> org.apache.xerces.xni.parser.XMLComponent interface:
>
> /**
> * Returns the default state for a feature, or null if this
> * component does not want to report a default value for this
> * feature.
> */
> public Boolean getFeatureDefault(String featureId);
>
> /**
> * Returns the default state for a property, or null if this
> * component does not want to report a default value for this
> * property.
> */
> public Object getPropertyDefault(String propertyId);
>
> The one thing you might immediately question is my use
> of a Boolean object instead of the boolean primitive. I
> use this so that the component can state that it doesn't
> care what the default value should be. This would be
> used in situations where the component may recognize and
> use a setting common to the parser configuration and/or
> other components, but where it doesn't care what the
> default is.
>
> And in fact, only the component that "introduces" the
> setting should set its default value. For example, both
> "validation" and "namespaces" are system wide settings
> and the parser configuration sets the default value. A
> lot of the components use these values but will take
> whatever default value has been established.
>
> What do you think? Can we roll this change into the
> codebase for Xerces 2.1.0?
>
> --
> Andy Clark * andyc@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
whatCanGoHere
Posted by Evert Hoff <ev...@pixie.co.za>.
Hi,
I am working on Xerlin (www.xerlin.org - an open source XML editor that
used to be called Merlot).
We are still using Xerces-1.4.0 and I want to now upgrade Xerlin to use
Xerces 2.
There are three essential functions for which we need access to the
Grammar in Xerces:
1. To determine which new elements may be inserted in a specific
location.
Xerlin has a tree structure with all the elements. Right-clicking on the
tree shows a pop-up menu with the names of the valid elements that may
be inserted there as children.
I used to use the whatCanGoHere method in DFAContentModel to find out
what may be inserted in a certain position, but can't find an equivalent
method in Xerces 2. Do you have any suggestions for how I could
accomplish this?
2. To validate whether the current children of a specific parent may all
be where they are.
This helps when a node is deleted, to find out if the remaining children
of the parent are still a valid set. We don't want to re-validate the
whole document just to find this out.
I have used the validateContent method in a ContentModel for this. It
looks like the validate method still does the same for DTDs. But, I
can't find something similar for Schemas. It looks like
XMLSchemaValidator is just for validating an entire document and not
just for a single element.
3. To quickly validate a single value of a specific element or attribute
to find out whether the value that the user entered is valid.
For this I used the datatypeValidator of an XMLElementDecl or an
XMLAttributeDecl. It looks like I can now use the validate method in
XSSimpleType for this.
---
Any suggestions would be appreciated.
Regards,
Evert
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org