[
Lists Home |
Date Index |
Thread Index
]
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@talsever.com alicorn@mindspring.com
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
|
