OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: SAX 2.0 Enhancement proposal (2nd Ed)


Jonathan Borden wrote:
>
> >
> > The weight of opinion then is on the side of change.  The
> > proposal for a new
> > interface in the next version of SAX (SAX 3.0?) remains unmodified so I
> > propose it goes onto the 'list of proposed enhancements' that I presume
> > David Megginson has tucked away somewhere to be resurrected when SAX
> > eventually goes to its new home.
>
> To be clear, I don't think that this feature warrants a change to the
> current SAX interfaces which would result in SAX 3.0. I consider James
> Clarks' suggestion a perfectly good solution to the issue using the
current
> SAX interfaces.

I agree that the proposed enhancement to SAX 2.0 is sufficient.  It is just
that it is a little counter-intuitive and could be improved in some future
version of SAX.  However, I guess you're right that it doesn't need to be
tabled - if it's still an issue in the future then it will be addressed at
that time.

> >
> > The proposal for a bug-fix to SAX 2.0 needs modification along
> > the lines of
> > James Clark's suggestion.
>
> I would not call this a bug fix, rather a request for a new standard
feature
> (and property). The current interface works as documented.

Yes, I did not mean to indicate otherwise.  I chose that term because David
Meggison indicated some time ago that we will be issuing a "bug fix" release
to SAX 2.0 and I thought this could proposal be included.  However, this is
really an enhancement and should be seen as such.

> >
> > 2) In order to furnish the application with the base URI of the entity
> > containing the ENTITY declaration, I would like your opinion on a choice
> > between:-
>
> > b) A new standard property: http://xml.org/sax/properties/baseURI.  This
> > property will contain the baseURI as described in (a) above.
>
> This is actually an important property to have, and is one of the (few)
> missing information items of the XML Infoset that SAX fails to provide. I
> think we need _both_ but I am more interested in the base URI property
than
> the standard feature.

Can I take that as a vote for option (b) - the creation of a new property,
leaving the systemId to contain just the system identifier from the xml
document?  If we are going to have a property containing the baseURI, there
is no need to overload the systemId parameter with it.

>  The value of this property will only be valid during the invocation of a
> resolveEntity() call.
>
> This property should be valid at all times. When the base URI is
> unknown/undefined the value can be null.

This sounds reasonable.


Many thanks for your input.

Regards
Rob Lugt




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC