[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Begging the Question (the novel)
Greetings Uche: Andrew wrote: > > > Much of the fruitless debate has been caused by reading into > > the specification things that it does not say. If you strip away these > > projections, what remains is less than has been fantasized but still much > > more than nothing. To which Uche Ogbuji replied: > > This is arrant nonsense. It almost seems as if you haven't been reading > the thread. Nothing inhuman, mind, I have such lapses quite often. But > it's pretty much beyond defense. On the contrary. It almost seems as if you haven't been reading any of the relevant specs covering these issues (XML Namespaces and XML Schemas). Here's what I was able to determine from the XML Namespace (http://www.w3.org/TR/REC-xml-names)and XML Schema Primer (http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#schemaLocation) specifications (1-6) 1) RE: http://www.w3.org/TR/REC-xml-names The XML Namespaces recommendation states the following quite plainly (and very politely too): " [Definition:] The attribute's value, a URI reference, is the namespace name identifying the namespace. The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. IT IS NOT A GOAL THAT IT BE DIRECTLY USABLE FOR RETRIEVAL OF A SCHEMA (IF ANY EXISTS)....However, it should be noted that ORDINARY URLS CAN BE MANAGED IN SUCH A WAY AS TO ACHIEVE THESE SAME GOALS." Translation: The value of an XML Namespace URI doesn't have to be an actual URL referencing an XML Schema, BUT IT COULD BE, if you wished to implement it that way in an application. This is an important and "good" thing. The value of the XML URI isn't REQUIRED to reference an actual schema, which means that the different namespace-aware xml processors (both validating and non-validating) can process each others' documents. <simon>Yeah yeah yeah -- XML 1.0 processors aren't namespace aware ...and the sky is falling because of it...yadda yadda...back at cha..etc. -- I'm trying to make a point here :-) </simon> 2) If you wish to use the value of your XML Namespace URI to actually reference a schema for validation, you may. If you wish to use one of XML Schemas' other built-in mechanisms for accomplishing such feats, you may do that too. And if you don't require validation, and only intend to use Xml Namespaces to disambiguate between a document's multiple vocabularies (SVG/XML, MathML/HTML, etc.) ...You can do that too! You have the power to make those kinds of decisions in the future, as situations arise. Having these options is not merely a postive side-effect of some ambiguity contained in the spec; this scenario provides a text-book example of XML's extensible architecture in action. Such usages are clearly permitted by the relevant namespace and schema standards, and constitute perfectly "legal" standards-compliant implementations, and in no way qualify as namespace "abuses". 3)The coast is clear with the XML Namespaces Recommendation, but how does this new-fangled freewheeling philosophy stand up against the requirements of XML Schema? Answer: It works like a charm. According to the Schema Primer Candidate Recommendation (http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#schemaLocation), XML Schemas provide SEVERAL different mechanisms that can be used to provide the location of a schema for validating a document and generating its "post-infoset contributions". (targetNamespace, "include/schemaLocation", "import namespace", where the location of the schema is the URL of the attribute value). Like XML Namespaces, their use is completely OPTIONAL. You may choose to implement any one of them, or use more than one at a time, none of them, or your own customized alternative. In fact, the XML Schema Primer document practically encourages such creative endeavors: "The schemaLocation attribute contains pairs of values: The first member of each pair is the namespace for which the second member is the hint describing where to find to an appropriate schema document. THE PRESENCE OF THESE HINTS DOES NOT REQUIRE THE PROCESSOR TO OBTAIN OR USE THE CITED SCHEMA DOCUMENTS, AND THE PROCESSOR IS FREE TO USE OTHER SCHEMAS OBTAINED BY ANY SUITABLE MEANS, OR TO USE NO SCHEMA AT ALL." "Note that the schemaLocation is ONLY A HINT and some processors and applications will have reasons to not use it; For example, an HTML editor may have a built-in HTML schema. You may also choose to not even use a namespace: "A schema is not required to have a namespace (see Section 3.4) and so there is a noNamespaceSchemaLocation attribute which is used to provide hints for the locations of schema documents that do not have target namespaces." 4) The Primer spec (http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#schemaLocation) practically encourages creative implementions for associating documents with their XML Schemas. According to the Schema primer, as long as conformant syntax is used, what your application uses to locate its schemas is up to the implementor. "The author of an instance document, such as a particular purchase order, may claim, in the instance itself, that it conforms to the rules in a particular schema. The author does this using the schemaLocation attribute discussed above. But regardless of whether a schemaLocation attribute is present, AN APPLICATION IS FREE TO PROCESS THE DOCUMENT AGAINST ANY SCHEMA. For example, a purchasing application may have the policy of always using a certain purchase order schema, regardless of any schemaLocation values." 5) As long as the document syntax, schema rules and validation/post infoset contribution processes are implemented consistently, the end results will be consistent across all XML 1.0 compliant/validating/namespace-aware parsers. As long as the mechanism used is successful at locating the schema and validating a source file against it, the actual methods used to locate the both files becomes less of an issue. In one situation, we might need our documents to be processed and validated on the client using a schema that was downloaded from a server. In a distributed Peer-to-Peer application, the schemas might "live" on the end-users' hard drives, requiring a totally different processing model. How the namespace URI value is used by an application is an IMPLEMENTATION issue, and as long as the syntax is clean, it's a friggin' free-for-all. 6) All this fuss over the last two years seems to have been caused by the fact that so many of us (myself included) were under the mistaken impression that, since the namespace URI value wasn't REQUIRED to be a URL, it also wasn't ALLOWED to be one. So us writer-types have to make a few corrections to our earlier works -- it's a small price to pay for finally getting it right and being able to now pass that correct information on to our readers/students. Most of my students are beginners anyway, perfectly happy with using XML Namespaces without really understanding the rationale behind each of the subparts of their namespace declartion. The "meaning" of the URI value in question was just part of that big ugly declaration they know they need to cut and paste into the root element of their document to get the XSLT or SVG processors to work right. However, I probably gat asked that question from throughly puzzled students more than anything else when I was teaching: "Where does the the namespace URI go to?" (Um. Nowhere. I just looks like a URI. It isn't one.) Why doesn't it go anywhere? Could it go somewhere? (No. It could say "ooga booga" and it would still work.) Have I ever thought about maybe having it go somewhere?......(You get the message) Now I realize they were confused because I was confused :-) *** In conclusion, this whole debate regarding how XML Namespace URIs "should" be used appears to be a bit of a non-issue when the XML Namespaces and XML Schema standards are taken into consideration. There are plenty of compatible options and most everything being suggested so far appears to be "legal". We can argue about which way is better, but they all seem be "fair game". The XML Namespaces spec wasn't deliberately under-specified or intentionally vague because its authors were hoping to obfuscate the shortcomings of an inherently faulty technology. (Why bother?) The mechanism described and its lack of restrictions regarding how the value of the namespace URI is used isn't a "bug" or a limitation, but rather a "feature" developed in the interest of interoperability :-) The namespace spec's functionality was already limited in scope without placing any further restrictions on its how it might be used. (At the time, the jury was still out for the most part among the xml expert community-at-large regarding how XML Namespaces would actually be used.) This isn't about a broken technology that's causing a hole in our hearts we need to fill up with religion. It's about maintaining a programming philosophy of utilizing what is available now while keeping our options open for the future. Such a strategy is "future-proofing" at its finest. I know it's not much, but it's about as good as future-proofing gets :-) Peace, lisa http://www.finetuning.com http://www.xml.com/resourceguide/ NOTE: I've included a complete excerpt in the bottom of this message from the XML Schema Part 0: Primer (http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#schemaLocation) in order to provide a clear context for the quotes I've sprinkled throughout this letter. Disclaimer: I am aware that the "primer spec" i will be referring to in below located at: http://www.w3.org/TR/xmlschema-0/ isn't really one of the two "main" schema specs (structures and datatypes), but rather a third, introductory-level explanatory specification (that is much better written and easier to understand). I thought it would provide a better explanatory reference under the circumstances. If you would like to read through a more complicated, fairly confusing explanation of the same material, the "real" spec is located at: http://www.w3.org/TR/xmlschema-1/#schema-repr **start excerpt Here's the extended excerpt that the above quotes were pulled from at URL: http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/primer.html#PO 5.6 schemaLocation XML Schema uses the schemaLocation and xsi:schemaLocation attributes in three circumstances. 1. In an instance document, the attribute xsi:schemaLocation provides hints from the author to a processor regarding the location of schema documents. The author warrants that these schema documents are relevant to checking the validity of the document content, on a namespace by namespace basis. For example, we can indicate the location of the Report schema to a processor of the Quarterly Report: Using schemaLocation in the Quarterly Report, 4Q99html.xml <purchaseReport xmlns="http://www.example.com/Report" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xsi:schemaLocation="http://www.example.com/Report http://www.example.com/Report.xsd" period="P3M" periodEnding="1999-12-31"> <!-- etc --> </purchaseReport> The schemaLocation attribute contains pairs of values: The first member of each pair is the namespace for which the second member is the hint describing where to find to an appropriate schema document. THE PRESENCE OF THESE HINTS DOES NOT REQUIRE THE PROCESSOR TO OBTAIN OR USE THE CITED SCHEMA DOCUMENTS, AND THE PROCESSOR IS FREE TO USE OTHER SCHEMAS OBTAINED BY ANY SUITABLE MEANS, OR TO USE NO SCHEMA AT ALL. A schema is not required to have a namespace (see Section 3.4) and so there is a noNamespaceSchemaLocation attribute which is used to provide hints for the locations of schema documents that do not have target namespaces. 2. In a schema, the include element has a required schemaLocation attribute, and it contains a URI reference which must identify a schema document. The effect is to compose a final effective schema by merging the declarations and definitions of the including and the included schemas. For example, in Section 4, the type definitions of Address, USAddress, UKAddress, USState (along with their attribute and local element declarations) from address.xsd were added to the element declarations of purchaseOrder and comment, and the type definitions of PurchaseOrderType, Items and SKU (along with their attribute and local element declarations) from ipo.xsd to create a single schema. 3. Also in a schema, the import element has optional nameSpace and schemaLocation attributes. If present, the schemaLocation attribute is understood in a way which parallels the interpretation of xsi:schemaLocation in (1). Specifically, it provides a hint from the author to a processor regarding the location of a schema document that the author warrants supplies the required components for the namespace identified by the nameSpace attribute. To import components that are not in any target namespace, the import element is used without a nameSpace attribute (and with or without a schemaLocation attribute). References to components imported in this manner are unqualified. Note that the schemaLocation is only a hint and some processors and applications will have reasons to not use it; For example, an HTML editor may have a built-in HTML schema. 5.7 Conformance An instance document may be processed against a schema to verify whether the rules specified in the schema are honored in the instance. Typically, such processing actually does two things, (1) it checks for conformance to the rules, a process called schema validation, and (2) it adds supplementary information that is not immediately present in the instance, such as types and default values, called infoset contributions. The author of an instance document, such as a particular purchase order, may claim, in the instance itself, that it conforms to the rules in a particular schema. The author does this using the schemaLocation attribute discussed above. But regardless of whether a schemaLocation attribute is present, an application is free to process the document against any schema. For example, a purchasing application may have the policy of always using a certain purchase order schema, regardless of any schemaLocation values. Conformance checking can be thought of as proceeding in steps, first checking that the root element of the document instance has the right contents, then checking that each subelement conforms to its description in a schema, and so on until the entire document is verified. Processors are required to report what checking has been carried out. To check an element for conformance, the processor first locates the declaration for the element in a schema, and then checks that the targetNamespace attribute in the schema matches the actual namespace URI of the element (or, alternatively, that the schema does not have a targetNamespace attribute and the instance element is not namespace-qualified). Supposing the namespaces match, the processor then examines the type of the element, either as given by the declaration in the schema, or by an xsi:type attribute in the instance. If the latter, the instance type must be an allowed substitution for the type given in the schema; what is allowed is controlled by the block attribute in the element declaration. At this same time, default values and other infoset contributions are applied. Next the processor checks the immediate attributes and contents of the element, comparing these against the attributes and contents permitted by the element's type. For example, considering a shipTo element such as the one in Section 2.1, the processor checks what is permitted for an Address, because that is the shipTo element's type. If the element has a simple type, the processor verifies that the element has no attributes or contained elements, and that its character content matches the rules for the simple type. This sometimes involves checking the character sequence against regular expressions or enumerations, and sometimes it involves checking that the character sequence represents a value in a permitted range. If the element has a complex type, then the processor checks that any required attributes are present and that their values conform to the requirements of their simple types. It also checks that all required subelements are present, and that the sequence of subelements (and any mixed text) matches the content model declared for the complex type. Regarding subelements, schemas can either require exact name matching, permit substitution by an equivalent element or permit substitution by any element allowed by an 'any' particle. Unless a schema indicates otherwise (as it can for 'any' particles) conformance checking then proceeds one level more deeply by looking at each subelement in turn, repeating the process described above. ***excerpt
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|