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>
