OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] [good] Question about NS 1.1

[ Lists Home | Date Index | Thread Index ]

At 5:31 PM +0200 4/12/02, james anderson wrote:
>"David G. Durand" wrote:
>  > This would be useful, but unless optional, it would make it harder
>>  for people to create stylesheets that produce non-namespaced,
>i don't see why this is harder. please give an example. i would have
>thought that the abstract syntax of such documents could be defined such
>that all names not in any namespace were actually in a distinguished
>"null" namespace.

I might want to put a colon prefix on a tag that is not (and will 
never be) associated with a namespace, for instance. More commonly, 
it's not uncommon to   want to omit a NS declaration in an output 
file because it's to be an external entity body that be included in 
another parsing context at a later time, and in which that namespace 
prefix will be properly bound.

>  > or non-xml results.
>i am unaware of this issue and would appreciate examples.

I'm outputting some other data format, but I want to embed a little 
piece of XML in the middle. The other data might establish a 
"namespace" binding in some other syntax. Or I might, as discussed 
above, be using colon prefixes to mean something else.

I might be needing to force colon prefixes to change in some odd way 
to accomodate a DTD that I want to conform to. Since DTDs don't know 
about the "semantics" of namespaces, that requires syntactic control 
over the prefixes. There's surely an annotation that could be added 
to a system like the one you want to ask for particular prefixes in 
particular places, but that starts to be a lot of complication to 
prevent a pretty easy to avoid error.

It's a tradeoff of flexibility versus automation of error prevention.

>  >
>>  There are even bigger holes in the XSLT type system, such as the
>>  ability to emit unescaped markup -- of course those are intended to
>>  solve tough problems (or enable quick hacks, depending on your
>>  perspective), and so their use is quite clearly marked.

David Durand                    |  12 Bassett St.
david.durand@ingenta.com        |  Providence RI, 02903-4628 USA
VP, Software Architecture       |  401-331-2014 x111 Cell: 401-935-5317
ingenta plc                     |  FAX: 401-331-2015


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS