[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Namespace declaration versus attribute
Totay. Lessee if I can present this any better. Given the following DTD: <!ELEMENT root( #PCDATA)> and given XML 1.0, pre-Namespaces processing, the following instance is DTD-invalid: <root xmlns="scheme://auth/path">text</root> This is because the DTD does not include an xmlns attribute in the root element content model. The following example, under the same processing conditions is also DTD-invalid: <ns:root xmlns:ns="scheme://auth/path">text</ns:root> In this case, the "ns:root" element is not recognized. Add namespace-awareness to the processor, and both examples are now DTD-valid. It follows that the namespaces recommendation either changes the content model of every element, permitting the xmlns attribute and any attribute in the namespace bound to the prefix xmlns (which is different than the namespace bound by the xmlns attribute). Or namespace declarations are not attributes. I cannot give an equivalent example of instances that are schema-invalid, because in order to check schema-validity, a processor must be namespace aware. However, the following fragment is at least redundant, and possibly in error: <xs:complexContent> <xs:attribute name="xmlns" type="xs:anyURI" use="optional" /> <xs:attribute name="ANY" namespace="http://www.w3.org/2000/xmlns" type="xs:anyURI" use="optional" /> </xs:complexContent> Or, in sum, namespace "attributes" are not (and should not be) declared, but their presence does not invalidate a content model that fails to explicitly include them. Moreover, the presence of these look-like-attribute, act-like-something-else causes structural (namespace-well-formed) changes to occur in the parsing/processing of an instance. Compliant parsers are "aware" of namespaces, which they take note of as they process, in a way that they are not (and need not) be aware of genuine attributes. These parsers, when directed to ensure namespace-well-formedness, keep track of current "scope" of the namespace declarations. "Scope" does not apply to your everyday attribute; it is scoped-by, not scoping. Namespace processing must occur within the parse process; namespaces are included in the infoset as separate, identifiable items not to be confused with attributes because the processing of these items causes changes to the processing of other things. This is the antithesis of layering. Namespace processing must happen at the same time as XML 1.0-defined processing, not before, not after, but within the process. It is only conceivable to propose that namespaces are layered on with DTDs, but one cannot validate by DTD namespace-unaware and then perform a namespace-aware pass. As I understand it, this is why namespaces are called out as separate items in the infoset. They are distinguished from attributes, because they feed back into the parse. They are, in a sense, "meta-attributes," attributes that supply meta-information to the parser, which the application may not really care about very much. Now, given that, then namespaces do not provide any support for "infoset extensions" or layering of processing. I do not believe that anything is gained by extending the infoset, because the infoset should be a complete representation of the content of a document. Thus it becomes more useful, when supplying additional information (such as the PSVI or the XQ/XP datamodel) to speak of a transformation of the infoset, a different model which does not modify the original, but is a result of some algorithm or process applied to it. Amy! -- Amelia A. Lewis amyzing@t... alicorn@m... Love doesn't just sit there, like a stone, it has to made, like bread, remade all the time, made new. -- Ursula K. Le Guin
|
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
|