Lists Home |
Date Index |
- From: Lisa Rein <email@example.com>
- To: "Simon St.Laurent" <SimonStL@classic.msn.com>
- Date: Tue, 02 Jun 1998 10:03:19 -0700
> In the long run, this is indeed true.
In the short term, however, this is not
> a WG project and we are not using WG 'due process'
Actually, this is precisely the reason for my pointing this out to you.
And it appears you still haven't heard me.
In the long term, OR the short term, it really makes no difference.
The process of defining XML schema IS a W3C process. You really need
to accept this without compromise. If any spec could be construed as
"unnecessary", surely it would be the one you are proposing
The WG is chugging away on the its schema agenda -- you couldn't
possibly need it THAT fast THAT Bad. You couldn't implement it on your
own if you wanted to -- I mean you COULD -- on your own computer -- but
I don't think such an implementation would be very useful -- not even to
- just public discussion
> leading to (hopefully) a rough consensus on a specification.
Hey Simon -- get a grip on yourself tough guy.
XML Schema IS XML. And XML is W3C project under the auspices of W3C's
due processes. Period.
And don't you ever forget it! Christ -- let's just all go and define
our own Namespaces -- Then we all work together to lead the last three
years of hard work right....down....the toilet!
This is indeed
> an experimental specification, but it is a specification we hope to complete
> by the end of June, _complete with namespaces_.
> It would be nice if some of this proposal survives as part of an eventual W3C
> specification, but it may well not. I'm focused on producing a workable
> specification, not contemplating its eventual demise.
Don't get your feathers ruffled Simon, but its inevitable eventual
demise is precisely what you MUST come to terms with and accept.
We could all produce our own "workable" specifications, and work
together to throw caution to the wind
-- without a care in the world or any concern about the potential
conflict with "that other XML schema definition".
Why exactly are you so hot and bothered by a desperate and immediate
need to design your own spec-dependent XSchema model??
-- MUCH LESS YOUR OWN NAMESPACE DEFINITION
(I know I didn't hear that ;-)
> >Also; why would XML schemas have a different prefix than their XML
> >documented counterparts -- XML Schemas will become part of the CORE
> >specification, yes?
> Someday they may, but we do need something for now. Their
Not may. Not Someday. They ARE. Right Now.
The WG chair (Jon Bosak) stated this as fact several weeks ago --
this isn't folklore or an old wives tale or a rumor or a warm fuzzy
feeling in the bottom of my heart -- it couldn't be any straighter from
Jon risked catching a little heat in making that announcement, but he
made it anyway in an attempt to stop us from wasting our time, or even
our energy wondering about it. A nice gesture, i thought.
> Someday they may, but we do need something for now.
No we don't. We can wait. Better we wait then do something that could
conflict or somehow confuse the "correct" way, when it is specified, in
the not-to-distant future.
> counterparts" use <! syntax, not instance syntax, so they didn't need another
Actually, if XML documents wish to reference all, or more crucially, if
they only with to reference PART of a particular schema - they WILL
need a prefix -- and the determined prefix would most likely depend on
certain conditions and requirement.
It these conditions and requirement that I envision being defined via
regular expressions. I don't see RE's providing some sort of substitute
for the for the structural rules defined in a schema model -- rather
such REs could used to determine WHICH schema model should be used.
And since everyone seems to be in agreement that a new prefix name does
not have to be introduced (it is NOT required) -- my little voice of
reason reminds that it's a bad idea to introduce prefix names just
because we like them, when we don't NEED them.
So with all that said -- and at the risk of ruffling more feathers,
Not to discourage creative implementations -- and I TOTALLY DIG YOUR
ENTHUSIASM -- however misguided :-) (take it from a fellow, albiet often
But we MUST protect our holy spec from such creative interpretation --
or we WON'T have the kind of standardized foundation strong enough to
sustain such creative implementations to occur without sacrifice in the
> John Cowan writes:
> JC>Thus it is not necessary to standardize a prefix, although
> JC>it certainly would be reasonable to recommend one.
> Precisely. So may we recommend XSC?
Do you have some life or death functionality keeping you awake at night
-- crying out for its own prefix name? Is your prefix emotionally
insecure or perhaps it has been hurt in the past by such stringent data
relationships (has it aquired a complex from its incompatibility with
other data types? :-) Does it have trouble expressing itself perhaps?
(sorry, I couldn't resist...)
I'll get to the point:
I propose we get this out of the way and agree NOW that the only
acceptable namespace implementation to adopt, at this stage, is
freshly-defined Namespace mechanism that has already been, nicely
explained and defined for us with TENDER LOVING CARE
you know, like in the WORKING DRAFT
delivered courtesy of the WORKING GROUP that was originally charged with
the task of doing so.
And Smile when we're do it too :-)
To devise any sort of indepently-devised namespace spec....
while at this very moment, a public working draft politely resides on
the W3C's site who respectfully requests your conformance, please...
just wouldn't be polite
it would be like.....
Like talking back to your mother!
Now go to your room!
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)