You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Neil Graham <ne...@ca.ibm.com> on 2003/05/07 00:17:22 UTC
Re: Schema Annotation
Hi Richard,
I've been meaning jump in to this thread for a while; hopefully I'll find
the time to keep on top of it this time. :)
You asked:
> 1) Is a SchemaElementDecl guaranteed to be invalid after a SchemaGrammar
> goes out of scope. I'm guessing yes, but want to confirm.
Yes. But, to be frank, this question is pretty much orthogonal to the
question of how one might implement a mechanism for getting at annotations;
this holds because almost *any* schema component can have annotations! See
3.x.1 for almost any value of x in the Schema Structures Spec [1]. So the
job of implementing support for schema annotations goes far beyond simply
adding methods to query annotations in SchemaElementDecl...
> 2) I have an implementation that works, but each SchemaAnnotation has its
The Hippocratic oath comes to mind here: "First, do no harm" :). i.e.,
when adding new functionality, we *must* take very good care to impact
existing performance--speed or memory--as little as possible.
While an implementation that joins DOM trees for schema documents to schema
grammars might possibly not kill speed performance (jury's out on that
though), it'll sure bloat the schema grammar for most users. One of the
things I think PeiYong has in mind for 2.4 is a way to enable grammars to
persist longer than the parser that created them; we sure don't want to
drag a bunch of dead old DOM's around if we don't have to.
So all this makes me think that, before going too much further down the
road of fleshing out our PSVI--and especially of doing heavy things like
supporting annotations--we must think about how to do it so the common case
(the case where the user doesn't care about annotations) remains
performant. I *hope* we can do this without introducing a whole new
scanner; i.e., I'd like to think we could do this under feature control (a
la schema-full-checking). But I don't yet know the code well enough to say
whether that'd work...
Thoughts from anyone?
Cheers,
Neil
[1]: http://www.w3.org/TR/xmlschema-1/#cModel_Group_Definitions
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
|---------+---------------------------->
| | Sir Woody |
| | Hackswell |
| | <woody@hackswell.|
| | com> |
| | |
| | 04/30/2003 03:34 |
| | PM |
| | Please respond to|
| | xerces-c-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: xerces-c-dev@xml.apache.org |
| cc: |
| Subject: Schema Annotation |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
Hello again!
I'm still trying to crunch out SchemaAnnotation class. :)
I have a few general questions.
1) Is a SchemaElementDecl guaranteed to be invalid after a SchemaGrammar
goes out of scope. I'm guessing yes, but want to confirm.
Assuming I'm right with #1:
2) I have an implementation that works, but each SchemaAnnotation has its
own document to hold the annotation DOMNodes internally. Wasteful. I know
TraverseSchema has a DOMParser (and in turn a DOMDocument). Would it be
possible to move the DOMParser to be owned by the SchemaGrammar instead so
that both the TraverseSchema and SchemaAnnotation classes can use the same
DOMDocument as a base for their nodes?
This way, only one DOMParser/Document needs to be created for the whole
process. TraverseSchema uses it anyway; I'm just suggesting that we move
it
to SchemaGrammar instead. Then, if a user needs serialized annotations, we
already have the DOMNodes in memory and can serialize, else, we pull in the
new document and deep clone the nodes out for a DOM implementation.
Comments? Suggestions? Criticisms? Jokes?
-Richard!
-----
If you could delete the recycle bin, where would it go?
Sir.Woody@Hackswell.com http://sir.woody.hackswell.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Schema Annotation
Posted by Sir Woody Hackswell <wo...@hackswell.com>.
On Tue, 6 May 2003 david_n_bertoni@us.ibm.com wrote:
> Hi all,
>
> I agree with what Neil has to say about avoiding an impact on performance
> for those who need access to annotation. On the other hand, storing
> annotations as DOM nodes is a good way of doing in a generic fashion.
>
> How about an option to turn this on along with storing the annotations in a
> hash table, similar to the way user data is stored? This has no impact on
> the size of the instance classes in the grammar, and only incurs overhead
> if the feature is enabled. It also means there's no need to touch every
> instance class in the schema grammar hierarchy.
>
> Dave
Yes, I was talking with Gareth about this as well. I was thinking of
something along the lines of a parser.setDoSchemaAnnotations([true|false]);
The problem comes with passing that flag into TraverseSchema. As my
implementation stands, it allocates the DOM only when something is added to
the SchemaAnnotation. So, at most, we add a few null pointers to the
SchemaElemenDecl (and other classes in the future).
My problem is this: People want both access as DOMNodes and Strings to the
annotations. I agree with this.
Problem with storing in DOMNodes:
1) I could make a document to hold each node (current implementation
=shudder=) inside the SchemaAnnotation, and deep clone when making a new
SchemaAnnotation. I'm thinking this is very bad overhead. ;)
2) Use just deep-cloned DOMNodes... but they go out of scope once leaving
TraverseSchema. Ouch.
2a) possible solution... have one document owned by the Grammar, and use it
to make/own all the nodes so they don't prematurely go out of scope. Should
be much less overhead. This again would be keyed by
setSchemaAnnotation(true).
Advantages to storing as DOMNodes:
1) TraverseSchema already handles DOM, so we just copy.
2) SchemaAnnotations are completely generic. DOMNodes/trees are perfect for
representing something non-specific, unlike the rest of the schema grammar.
3) Easy to convert to Strings with DOM-LS. (writeToString)
Problem with storing as strings:
1) How to convert strings back to DOMNodes.
2) "Waste" of processing time to convert DOMNode->string->DOMNode.
Advantages of storing as Strings:
1) Strings are fully-owned by the SchemaAnnotation, are easily copied, don't
go out of scope prematurely.
> I've been meaning jump in to this thread for a while; hopefully I'll find
> the time to keep on top of it this time. :)
>
> You asked:
>
> > 1) Is a SchemaElementDecl guaranteed to be invalid after a SchemaGrammar
>
> > goes out of scope. I'm guessing yes, but want to confirm.
>
> Yes. But, to be frank, this question is pretty much orthogonal to the
> question of how one might implement a mechanism for getting at annotations;
> this holds because almost *any* schema component can have annotations! See
> 3.x.1 for almost any value of x in the Schema Structures Spec [1]. So the
> job of implementing support for schema annotations goes far beyond simply
> adding methods to query annotations in SchemaElementDecl...
>
> > 2) I have an implementation that works, but each SchemaAnnotation has its
>
> The Hippocratic oath comes to mind here: "First, do no harm" :). i.e.,
> when adding new functionality, we *must* take very good care to impact
> existing performance--speed or memory--as little as possible.
>
> While an implementation that joins DOM trees for schema documents to schema
> grammars might possibly not kill speed performance (jury's out on that
> though), it'll sure bloat the schema grammar for most users. One of the
> things I think PeiYong has in mind for 2.4 is a way to enable grammars to
> persist longer than the parser that created them; we sure don't want to
> drag a bunch of dead old DOM's around if we don't have to.
>
> So all this makes me think that, before going too much further down the
> road of fleshing out our PSVI--and especially of doing heavy things like
> supporting annotations--we must think about how to do it so the common case
> (the case where the user doesn't care about annotations) remains
> performant. I *hope* we can do this without introducing a whole new
> scanner; i.e., I'd like to think we could do this under feature control (a
> la schema-full-checking). But I don't yet know the code well enough to say
> whether that'd work...
>
> Thoughts from anyone?
>
> Cheers,
> Neil
>
> [1]: http://www.w3.org/TR/xmlschema-1/#cModel_Group_Definitions
>
> Neil Graham
> XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: neilg@ca.ibm.com
>
>
>
>
> |---------+---------------------------->
> | | Sir Woody |
> | | Hackswell |
> | | <woody@hackswell.|
> | | com> |
> | | |
> | | 04/30/2003 03:34 |
> | | PM |
> | | Please respond to|
> | | xerces-c-dev |
> | | |
> |---------+---------------------------->
>
> >---------------------------------------------------------------------------------------------------------------------------------------------|
>
> |
> |
> | To: xerces-c-dev@xml.apache.org
> |
> | cc:
> |
> | Subject: Schema Annotation
> |
> |
> |
> |
> |
>
> >---------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
> Hello again!
>
> I'm still trying to crunch out SchemaAnnotation class. :)
>
> I have a few general questions.
>
> 1) Is a SchemaElementDecl guaranteed to be invalid after a SchemaGrammar
> goes out of scope. I'm guessing yes, but want to confirm.
>
> Assuming I'm right with #1:
>
> 2) I have an implementation that works, but each SchemaAnnotation has its
> own document to hold the annotation DOMNodes internally. Wasteful. I know
> TraverseSchema has a DOMParser (and in turn a DOMDocument). Would it be
> possible to move the DOMParser to be owned by the SchemaGrammar instead so
> that both the TraverseSchema and SchemaAnnotation classes can use the same
> DOMDocument as a base for their nodes?
>
> This way, only one DOMParser/Document needs to be created for the whole
> process. TraverseSchema uses it anyway; I'm just suggesting that we move
> it
> to SchemaGrammar instead. Then, if a user needs serialized annotations, we
>
> already have the DOMNodes in memory and can serialize, else, we pull in the
>
> new document and deep clone the nodes out for a DOM implementation.
>
> Comments? Suggestions? Criticisms? Jokes?
>
> -Richard!
>
>
>
> -----
> If you could delete the recycle bin, where would it go?
>
> Sir.Woody@Hackswell.com http://sir.woody.hackswell.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
--
-----
"Many waters cannot quench Love. / Rivers cannot wash it away.
If one were to give all the wealth / Of his house for Love,
It would be utterly scorned." (Song of Songs 8:7)
Sir.Woody@Hackswell.com http://sir.woody.hackswell.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Schema Annotation
Posted by da...@us.ibm.com.
Hi all,
I agree with what Neil has to say about avoiding an impact on performance
for those who need access to annotation. On the other hand, storing
annotations as DOM nodes is a good way of doing in a generic fashion.
How about an option to turn this on along with storing the annotations in a
hash table, similar to the way user data is stored? This has no impact on
the size of the instance classes in the grammar, and only incurs overhead
if the feature is enabled. It also means there's no need to touch every
instance class in the schema grammar hierarchy.
Dave
"Neil Graham"
<neilg@ca.ibm.co To: xerces-c-dev@xml.apache.org
m> cc: (bcc: David N Bertoni/Cambridge/IBM)
Subject: Re: Schema Annotation
05/06/2003 03:17
PM
Please respond
to xerces-c-dev
Hi Richard,
I've been meaning jump in to this thread for a while; hopefully I'll find
the time to keep on top of it this time. :)
You asked:
> 1) Is a SchemaElementDecl guaranteed to be invalid after a SchemaGrammar
> goes out of scope. I'm guessing yes, but want to confirm.
Yes. But, to be frank, this question is pretty much orthogonal to the
question of how one might implement a mechanism for getting at annotations;
this holds because almost *any* schema component can have annotations! See
3.x.1 for almost any value of x in the Schema Structures Spec [1]. So the
job of implementing support for schema annotations goes far beyond simply
adding methods to query annotations in SchemaElementDecl...
> 2) I have an implementation that works, but each SchemaAnnotation has its
The Hippocratic oath comes to mind here: "First, do no harm" :). i.e.,
when adding new functionality, we *must* take very good care to impact
existing performance--speed or memory--as little as possible.
While an implementation that joins DOM trees for schema documents to schema
grammars might possibly not kill speed performance (jury's out on that
though), it'll sure bloat the schema grammar for most users. One of the
things I think PeiYong has in mind for 2.4 is a way to enable grammars to
persist longer than the parser that created them; we sure don't want to
drag a bunch of dead old DOM's around if we don't have to.
So all this makes me think that, before going too much further down the
road of fleshing out our PSVI--and especially of doing heavy things like
supporting annotations--we must think about how to do it so the common case
(the case where the user doesn't care about annotations) remains
performant. I *hope* we can do this without introducing a whole new
scanner; i.e., I'd like to think we could do this under feature control (a
la schema-full-checking). But I don't yet know the code well enough to say
whether that'd work...
Thoughts from anyone?
Cheers,
Neil
[1]: http://www.w3.org/TR/xmlschema-1/#cModel_Group_Definitions
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@ca.ibm.com
|---------+---------------------------->
| | Sir Woody |
| | Hackswell |
| | <woody@hackswell.|
| | com> |
| | |
| | 04/30/2003 03:34 |
| | PM |
| | Please respond to|
| | xerces-c-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: xerces-c-dev@xml.apache.org
|
| cc:
|
| Subject: Schema Annotation
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Hello again!
I'm still trying to crunch out SchemaAnnotation class. :)
I have a few general questions.
1) Is a SchemaElementDecl guaranteed to be invalid after a SchemaGrammar
goes out of scope. I'm guessing yes, but want to confirm.
Assuming I'm right with #1:
2) I have an implementation that works, but each SchemaAnnotation has its
own document to hold the annotation DOMNodes internally. Wasteful. I know
TraverseSchema has a DOMParser (and in turn a DOMDocument). Would it be
possible to move the DOMParser to be owned by the SchemaGrammar instead so
that both the TraverseSchema and SchemaAnnotation classes can use the same
DOMDocument as a base for their nodes?
This way, only one DOMParser/Document needs to be created for the whole
process. TraverseSchema uses it anyway; I'm just suggesting that we move
it
to SchemaGrammar instead. Then, if a user needs serialized annotations, we
already have the DOMNodes in memory and can serialize, else, we pull in the
new document and deep clone the nodes out for a DOM implementation.
Comments? Suggestions? Criticisms? Jokes?
-Richard!
-----
If you could delete the recycle bin, where would it go?
Sir.Woody@Hackswell.com http://sir.woody.hackswell.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org