Hi Arun,
Thanks for your initiative in this. I've also given some thought to how to
implement XPointer support. I'm still thinking about your proposed design,
but one suggestion I do have is that XPointer fragments should not be
detected by the XInclude processor. Since the XPointer framework is a
recommendation which is not dependent on XInclude, it would be adding an
unnecessary restriction in Xerces to force an XInclude processor into the
pipeline if we want XPointer support.
Terminology to avoid confusion:
XPointer schema processor - a component which is able to handle a
particular type of XPointer schema. Parses the schema data from the
document fragment, filters the XNI events to only allow events through
which match the schema data. Reports if a subresource was identified.
XPointer processor - the component in the pipeline which detects the use of
a document fragment, detects the type of schema, spawns XPointer schema
processor as necessary, reports failure if no sub-resources could be found
In your suggestion, you have the XInclude processor take on the role of
XPointer processor, as well. This simplifies some aspects of implementing
it (described below), especially if XPointer support is only intended to be
used with XInclude.
I think a better solution is to have a separate component be the XPointer
processor, which would be placed in the pipeline before the XInclude
processor. This would allow users to have XPointer support without
XInclude support, and also XInclude support without XPointer (although
technically that wouldn't conform to the spec, users who know they won't
use document fragments could opt for the efficiency boost). It would also
simplify the XInclude processor, since it would not need to know that it is
receiving a document fragment or a whole document; either way it just gets
a stream of XNI events.
The difficulty in implementing it this way is that the XPointer processor
requires control over the document scanner, since it needs to be able to
re-open the document stream for each XPointer schema processor (and
possibly multiple times for a single XPointer schema processor). In your
suggestion, this is simplified, because the XInclude processor is outside
of the newly created partial pipeline, and so can simply remake a new
pipeline when it wants to reset the document scanner. I don't think it's
possible for a regular pipeline component to reset the scanner from inside
the pipeline.
One possible solution, which I prefer at the moment, is make the XPointer
processor an implementation of the document scanner. Thus, it would have
control over itself, and over the document stream. It would be able to
reset the stream when it finds that a schema component didn't identify any
subresources, while maintaining the transparency to components further in
the pipeline.
What are peoples comments on this?
Peter McCracken/Toronto/IBM
Arun Yadav
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
om> cc: Elena Litani/Toronto/[EMAIL
PROTECTED], Peter McCracken/Toronto/[EMAIL PROTECTED],
[EMAIL PROTECTED]
08/07/2003 02:53 Subject: XPointer Support for XInclude
in Xerces.
PM
Please respond to
xerces-j-dev
Hi,
As of now, xerces doesn't not provide the support for XPointer Framework
[http://www.w3.org/TR/xptr-framework/] and XPointer element()
[http://www.w3.org/TR/xptr-element/] schema which are required to be fully
complaint for XInclude. I am planning to provide the support
for XPointer into xerces-java. As per XInclude spec element() schema and
XPointerFramework needs to be supported. XPointerFramework
insist that any schema should be processed by the XPointer processor.
Proposed Design : XPointer support will be provided on top of the
XInclude which is designed by Peter,IBM.
XPointer processor will be initialized only if XInclude processor
identifies the pointer part in the URI to be included. If
XInclude processor recognizes the pointer part in URI then it will spawn
a new partial xpointer pipeline which will have xpointer
schema component to process the schema pointer. If sub-resource is not
identified by schema then Xpointer processor will re-open's the
inputsource for next schema in pointer part. XPointer Schema will be a XNI
component which implements the XPointerSchema interface.
Application developer can register his Xpointer schema into XPointer
processor with the help of property shown below
Property Name: http://xml.apache.org/xerces/xpointerschema.
Property Value: XPointerSchema [].
It may be possible that user wants to register
multiple Xpointer schema's into a XPointer Processor.
/**
* Application developer should extends XPointerSchema to define its own
Xpointer schema.
*
*/
public interface XPointerSchema extends XMLDocumentFilter{
/**
* This function return the Schema name which is used by the
XPointer Processor to identify schema object.
*
* @return The name of XPointerSchema Component.
*/
public String getXPointerSchemaName();
/**
* set the schema pointer for Schema to process.
*/
public void setSchemaPointer(String pointer);
/**
* return true if sub-resource is identified by the schema component.
*/
public boolean isSubResourceIdentified();
}
Your valuable comments and queries are welcome.
Thanks,
Arun.
Sun Microsystems, India.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
