[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [Fwd: Defining "public interfaces" inspecifications]

• To: Eric van der Vlist <vdv@d...>, xml-dev@l...
• Subject: Re: [Fwd: Defining "public interfaces" inspecifications]
• From: Elliotte Rusty Harold <elharo@m...>
• Date: Sat, 26 Oct 2002 09:00:40 -0400
• In-reply-to: <1035620773.3402.5.camel@ibook>
• References: <1035620773.3402.5.camel@ibook>

At 10:26 AM +0200 10/26/02, Eric van der Vlist wrote:

>If that had been the case, other specs such as XPath 1.0 could have
>refered to "the latest definition of a XML Name" instead of nominatively
>quote "the current definition of a XML Name in XML 1.0".

I think this is a disaster for interoperability. Currently, I know 
what an XPath 1.0 processor does. I know what it considers to be a 
name. Under this scheme different XPath processors would produce 
different results when applied to the same data depending on what 
version of XML Names was in use.

Maybe you could come up with some way of specifying which version of 
XML Names an expression required, but that would seem difficult in 
the context of XPath, especially when you mix it with versions of 
namespaces, versions of URIs, and anything else for which you might 
need to identify the latest version.

>This has already been done with external specs and, for instance, XSLT
>1.0 relies on the fragment definition for the mime type of the
>dereferenced document in the definition of the document() function. In
>other words, XSLT 1.0 relies on whatever will the definition of a XML
>fragment be.

Has anybody actually tested this to see how XSLT processors behave? 
and whether they all do the same thing? I tend to think this will 
also cause interoperability problems, even once XPointer gets sorted 
out. I suspect it would have been better for XSLT to ignore fragment 
identifiers completely, until after XPointer had been finished so it 
could determine whether and how to incorporate them.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@m... | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

• Follow-Ups:
  • Re: [Fwd: Defining "public interfaces" in specifications]
    • From: Eric van der Vlist <vdv@d...>

• References:
  • [Fwd: Defining "public interfaces" in specifications]
    • From: Eric van der Vlist <vdv@d...>

• Prev by Date: Re: We need SAX features to say a parser supports XML
• Next by Date: RE: ANN: xpath1() scheme for XPointer
• Previous by thread: RE: [Fwd: Defining "public interfaces" in specifications]
• Next by thread: Re: [Fwd: Defining "public interfaces" in specifications]
• Index(es):
  • Date
  • Thread