[
Lists Home |
Date Index |
Thread Index
]
bryan wrote:
>>transform: elements and children in the unknown namespace are
>>transformed into known elements and text. Ex: Henry Thompson's normal
>>forms.
> Thanks for the mention of normal forms, hadn't seen it before, now I
> have some reading for next weekend. However looking at what I googled up
>
> http://www.ltg.ed.ac.uk/~ht/normalForms.html
>
> I couldn't see right off how one manages transform of unknown namespace
> elements to known elements and text:
Here is an entirely trivial example:
<x:foo xmlns:x="unknown" a="1" x:a="2">
<y:bar xmlns:y="other"/>
</x:foo>
Becomes:
<element name="foo" ns="unknown" xmlns="known">
<attribute name="a" value="1"/>
<attribute name="a" ns="unknown" value="2"/>
<text>
</text>
<element name="bar" ns="other"/>
<text>
</text>
</element>
(I think I got this from a post by Simon St. Laurent.) It's a kind of
transparent tunneling.
> If I have <x:code xmlns:x="urn:whatever:namespace">90952</x:code>
> somewhere in the xml coming into my application, and I have absolutely
> no knowledge of the namespace and the element of local name code in it,
> how does normal Forms or any technology help me to securely transform
> that to <zip>90952</zip>. This is what I think you're saying it does,
> and this is what I find strange and mystifying that it could do,
> although I am willing to be astounded if it be so.
It's not about meaning, it's about markup. You don't have to lose
information just because you don't understand it.
Bob
>>In the spirit of your list, this doesn't include strategies by which
>>unknown namespaces become known, such as James Clark's NXML locate and
>>David Tolpin's Regular Associations, recently mentioned on this list.
>
>
> Thanks for the info, still not sure if I understand the Regular
> Associations post yet. Yeah, how an unknown namespace becomes known
> isn't what I'm interested in right now. What I'm thinking about
> specifically is models for how unknown namespaces are treated that
> remain unknown all the way through an application, mainly because we
> have an application in which I suppose that is going to be a big
> problem.
|
