Re: [regrep] FW: Namespace management

[Chiusano Joseph <chiusano_joseph@bah.com>]

<Quote>
This is obviously a recipe for chaos - and in the US Gov
XML WGs meetings I've sat in - and where these requests
for namespace management are coming from - that is
what I see is part of the perception - that each department
within the USGov will own its own prefixes and use these
to label its own content.
</Quote>

I believe the perception may be that each department within the USGov
will own its own *namespace identifier* (not prefixes) and this
namespace identifier to label its own content (through prefixes).

Joe

David RR Webber - XML ebusiness wrote:
> 
> Matt,
> 
> I think I touched a few live wires here!
> 
> Yes - I intended to make people stop and
> re-assess their thinking.
> 
> But we're not talking about the same two things.
> 
> From what I've seen of your use of namespaces - you
> you them in an appropriate programmer-centric way
> that delimits special purposed markup "families" within
> a overall block of markup - (e.g. XQuery instructions
> enbedded into content) and yes - writing code to
> handle that is not tough.
> 
> What I've seen elsewhere is the opposite arena - where
> non-technical users believe that the only way to make
> their markup functional is if they assign prefixes to everything.
> 
> This is obviously a recipe for chaos - and in the US Gov
> XML WGs meetings I've sat in - and where these requests
> for namespace management are coming from - that is
> what I see is part of the perception - that each department
> within the USGov will own its own prefixes and use these
> to label its own content.
> 
> This IMHO will significantly impede interoperability
> and deployment of agile information.  Worse - if we
> institutionalize this - then we will be making this whole
> mindset part of the culture of "how" XML is done.
> 
> Premise #1 in my book is that the LESS markup goes
> into the exchange transaction structures the better
> on all counts of ease of implementation, maintenance,
> interoperabilty and reduction of content bloat.
> 
> Do not confuse semantics with content.  Keep the two
> separate as much as possible.
> 
> Now also look at some other down sides - if people
> think they can own and manage namespace prefixes,
> then you get into turf wars - but legally you cannot
> "own" such things - this is just an invitation to lawyers
> that I'd rather avoid - especially if this crosses over
> from the government arena to the "wild".
> 
> OK - nows lets look at the POSITIVES here.  I reckon
> that if we accept the following premises:
> 
> 1) Namespaces used to denote special purpose
>       markup is an essential and needed mechanism,
>      such uses are driven off the URI - not the prefix!
> 
> 2) Discovery of namespace usage as int 1).
> 
> 3) Prefix-centric namespace thinking geared around
>      making names "unique" within a XML transaction
>      does not adequately solve eBusiness needs -
>      particularly not versioning of items, and not
>      context driven content.
> 
> 4) People want to own prefixes and have the
>      registry manage and enforce content submission
>      rules for them.
> 
> So - looking at items 1) & 2) - the Registry can ALREADY
> handle these very nicely - if you just want to catalogue
> these - so you know that someone already has a
> toolset to handle XQuery say - and you want to
> query on a URI - find the owner - description - purpose,
> etc, we can do that by having yet-another extrinsic type
> within Registry as a non-normative addendum.
> 
> Items 3) and 4) I think we do want to wave a red flag
> and point out to people that they need to re-think their
> understanding of their use cases.
> 
> OK - I stand guilt of trying to drive a CAM shaped nail
> into every problem I see at the moment  ; -)
> 
> Please understand that I'm striving to make CAM
> leverage the XML toolset world - NOT replace it!
> 
> Especially I see that the role of ebXML generally
> is to encourage best-practices and a clear ROI
> roadmap for ebusiness - and so we should be
> making it easier for end users to adopt and use
> XML  -and also ensuring that there are not ugly
> ramifications longterm.
> 
> Hope this now makes a lot more sense - and
> clarifies the issues here.
> 
> Thanks, DW.
> ====================================================
> Message text written by Matthew MacKenzie
> >
> David,
> 
> See inline.  I see you are flogging the
> CAM-redefines-XML-namespace-and-XML-Schema idea.
> 
> :-)
> 
> >I stressed the above to show how this is different.  I guess I
> >never bought into the premise from the W3C that
> >you HAD to have a unique prefix on your XML, else
> >it would not "work".   I find this flawed, and further more
> >users react badly when asked to add prefixes to tags,
> >and mapping software reacts even worse when asked
> >to manage and move content so labelled.
> >
> 
> Whoa!  Are we debating the use of namespaces here?  We were discussing a
> "registry of namespaces", and certainly not a registry of namespace
> prefixes, and even more certainly we were not discussing the
> apropriateness of XML namespaces.
> 
> The idea that every bit of XML is a member of a namespace is A Good
> Thing.  And if "mapping" software has a problem dealing with properly
> namespaced XML, perhaps those mapping software vendors ought to make use
> of one of the 15+ open source XML parsers, that can handle namespaces.
> Hell, a few years ago I wrote a XML parser using regular expressions
> that dealt with namespaces.  Its not hard.  I'd like to know why you
> think namespaces are flawed.
> <
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