[
Lists Home |
Date Index |
Thread Index
]
<Quote1>
What if later you want to extract the original XML content from the
HTML? Can't do it, all the namespaces are gone buddy.
</Quote1>
I see where you're going with this. In a Namespace Manager (such what as
I'm working on for ebXML Registry), both namespace identifiers (i.e. the
standard XHTML namespace ID and the namespace ID that the "my" prefix is
associated with - I'll refer to it as the "my" namespace ID) would both
exist as entities in the registry. When the XML document (or schema) is
originally registered in the registry, the registry would parse the
document, automatically register the "my" namespace ID (if it doesn't
already exist in the registry), automatically register all artifacts
(elements/attributes/datatypes), and automatically associate each
artifact with its namespace (the "my" namespace).
Then, a user decides that the artifacts in the "my" namespace (this is
just one of multiple paths) should be "transferred" to the XHTML
namespace. They do this through a registry request, select the pertinent
XML document(s) that should be affected, select a new namespace prefix
(if desired), and the registry automatically makes the necessary changes
in the XML documents.
The audit log of the registry also preserves all actions taken, so a
record would be kept of all actions.
<Quote2>
So instead over converting <my:body> to <xhtml:body>, just prepend the
xhmtl prefix (and I mean a Namespaces in XML prefix) to the existent
'my' prefix:
<xhtml:my:body>
</Quote2>
Way too complex and overdone - see above for a much more elegant
solution. I really think that that's road we need to continue forward
on. This is the equivalent of turning edits on in Word in a printed
document (for a final version!), so that the client can see all updates
that were made along the way.
<Quote3>
Yet another processor can work magic by knowing that *both* namespaces
have been associated
</Quote3>
Yes - and the registry retains this information.
<Quote4>
So I'm waiting for somebody knowledgeable to tell me why this is a
crappy idea.
</Quote4>
It's a great idea.
<Quote4>
I really haven't thought through the horrific consequences that are
sure to follow.
</Quote4>
I've thought through many of them over the past year and a half - so
let's keep the dialogue going.
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Jeff Lowery wrote:
>
> > Why would one want to do this? What advantages would it afford? In what
> > scenarios would it be useful?
>
> Okay, this is a completely different topic from the last permathread.
>
> Say I want to take some XML formatted content and merge it into an HTML
> document. Some of the elements are directly translatable to HTML elements,
> but not others. Say I have a <my:body> in my content. I want to present that
> as <xhtml:body>. There are other elements in the content that are not
> correspondent with HTML elements, even though their names the same. Say for
> example, I have a <my:title> element (if Bob DuCharme was reading this he'd
> point out that it is a tag, not an element, but you know what I mean; sloppy
> is as sloppy does).
>
> Anyhow, you can write an XSLT script that converts some content to HTML, and
> leaves the rest alone. But you've lost information in the conversion. What
> if later you want to extract the original XML content from the HTML? Can't
> do it, all the namespaces are gone buddy.
>
> Yeah, there are workarounds. You could preserve the content in comments. I
> suppose there are better ways, I just don't do document mixing that often,
> lucky me.
>
> Still, it seems the simplest way to preserve namespace information is not to
> ditch it in the first pass, but preserve in a manner that was close to the
> way it was originally presented. So instead over converting <my:body> to
> <xhtml:body>, just prepend the xhmtl prefix (and I mean a Namespaces in XML
> prefix) to the existent 'my' prefix:
>
> <xhtml:my:body>
>
> What good does this do? Well the browser can see the xhtml namespace
> association, ignore the 'my' namespace association, and do the write thing
> with the body content. A process that wants to extract the original content
> from the XHTML (say it's soooo far down the line that it doesn't know where
> the original content originated from) can do so because the original
> namespace association can still be had.
>
> Yet another processor can work magic by knowing that *both* namespaces have
> been associated (I wouldn't necessarily say *in*, but perhaps I should) with
> the body element. Maybe it wants to extract original content while
> preserving format, for instance.
>
> So I'm waiting for somebody knowledgeable to tell me why this is a crappy
> idea. I really haven't thought through the horrific consequences that are
> sure to follow.
begin:vcard
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard
|
