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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] Re: determining ID-ness in XML

On Fri, Nov 09, 2001 at 02:26:29PM -0600, Bullard, Claude L (Len) wrote:
> That is one explanation.   However:
> 1.  No one has stated a requirement that the name actually 
> be an ID.  A name will do.  (see elliotte).  If a 
> name will do, this is a nameloc and there is not a gaping 
> hole in the architecture.

  The requirement is to be able to use a simple name for the fragment
identifier. There is an implicit requirement for compatibility
reason with the only widely fragment identifier syntax deployed (text/html)
and because since 1.0 was release *everybody* expected #foo to 
point to the ID foo (or the first ID of name foo in the document order
if you take the XPath viewpoint). If you break either of those
you miss the 80/20 usercase sweet spot.

> 2.  If that is not the case, and it must be an ID, then 
> what the xml:id proposal does is begin to marginalize 
> the use of DTDs.

  The fact that it is needed is an explicit acknoledgement that
DTDs are *already* marginalized. (For the record, Libxml parsing mode
defaults to well formedness, won't read the external subset, won't
fetch the DTD by default, I have yet to receive a *single* complaint
about this being the default. To me it is the proof that at least most
of the users of my toolkit, when they use it for simple XML processing
do not dare to run the parser in validating mode.)

> Otherwise, no change.  It costs too much to 
> allow the children to play in the design these days.

  You're so pedantic when you imply that you hold the REAL TRUTH,
I have the feeling I'm listening CNN from here (France).


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/