Re: [regrep] FW: Namespace management

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

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.
<


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>