- From: Al Gilman <asgilman@iamdigex.net>
- Date: Sat, 03 Jun 2000 12:10:41 -0500
- To: <xml-uri@w3.org>
At 09:52 PM 2000-06-02 -0400, Tim Berners-Lee wrote: > >I missed this simply put assertion that a difference >in identity between layers is broken. I am sorry, you seem to have both missed the point. Namespaces, per se, don't posess identity. There is no sufficiently useful and general equivalence test for namespaces by which to define namespace identity. Identity for individual namespaces will be found in subclasses of namespaces, not in the namespace domain itself. The XSLT namespace is an example of this. Namespaces all have a common mode of recognizability, but not _namespace_ identity. XSLT does not condone the use of its namespace for "general namespace use;" only when applied under the further restrictions also articuated in the XSLT language specification. The namespaces recommendation defines the method by which one distinguishes XSLT elements and attributes from other elements and attributes when mixed in a polyglot XML instance document. But it does not define how much semantics one is expected to conform to in the processing of these elements and attributes. That is left to the definers of the individual namespaces. Without such a basis for comparing namespaces, there is no namespace-generic way to determine that two namespaces are equivalent, that they bind to the same proper knowledge at some defined level of partial understanding. Lacking a reasonable and useful comparison of equivalence, identity is not something that should be entertained. >From: Clark C. Evans <cce@clarkevans.com> >Date: Sunday, May 28, 2000 3:01 PM >[...] > >>Further, I am strongly against specs re-defining >>behavior at a higher layer under the context of >>"layered is modular". This is just a falicy. >>If the namespace spec defines when two namespace >>names are equivalent, then layered specs should >>respect this definition and not re-define it. In the layered solution, the Namespaces spec does not define when two namespaces are equivalent. It defines when a distinction should be preserved between several collections of names for the duration of some defined initial segment of processing, often referred to as a lower layer. >>To do so will cause inconsistency amoung the >>layered specifications; i.e. RDF will do it one >>way, XPath will do it another, and now a given >>text that I have will only work with RDF *or* >>with XPath, but not both. This does not happen if the processing modules progress by pure refinement. Each module adds knowledge but cannot take away. If we make it clear what domains of knowledge are elucidated in each module, the modules do not work at cross purposes and RDF _knows_ when it must apply XPath first before doing its thing, for example. The application scenario introduced before is one where two schemata define type systems where one includes an import from the other. The layered proposal is that the lower layer treats the indicated spaces of names as different, and hence the type names appearing in the two imported spaces are treated as different in this lower layer. A schema-aware upper layer may also know that the schemata overlap; they contain a common element. The type is the same even though the names [as used in the XML instance document] are different. There is no declaration of equivalence at the lower layer. There is just a unary recognition "Do I know this namespace?" That is all that is defined in the Rec. The layering does not involve rewriting Macintosh apples into Golden Delicious. It involves rewriting "fruit for lunch" into "Golden Delicious apple." The lower layers process items in accordance with supertypes to which the items conform and which the lower layers comprehend. The upper layers process items in accordance with finer types to which the items also conform. These finer types are subtypes of the supertypes comprehended by the lower layers. The upper layers comprehend the type refinements between the lower-layer-processed supertypes and the types they handle. It is consistent throughout. In fact, because Namespaces as used in the Namespaces in XML Recommendation are such a weak superclass, it is generally inappropriate to talk about comparing namespaces per se. As discussed above, althought the XSLT language does define a namespace, XSLT is not just a namespace. On detecting that one is dealing with the namespace of the XLST language, namespace processing insofar as syntactic construction of the element and attribute tree may progress just as with any other namespace, but the comprehension of the language has not been completed and higher layers are required to complete the processing of the content marked with names in this namespace. When you recognize that you know this namespace, you are also obligated to recognize that the document is using the XSLT language, not _just_ names from the XSLT namespace. The lower layer can process the syntax without knowing about this. The identity of this namespace is derived from the identity of the language, and not from any definition of a namspace with an autonomous identity. Beyond the "lower layer" of syntax tree construction, one does not generally want to compare namespace to namespace; one wants to compare "language slices" or other stronger classes of structure. The appropriate comparison involves knowledge not addressed in the Namespaces Rec. and that is why in order to retain the capability to extend the depth of XML dialects, it is important to clarify the semantics of the Namespaces Rec. in this minimalist and extensible or 'layered' way. Al
Received on Saturday, 3 June 2000 11:56:52 UTC