But Michael can, of course, better clarify for himself exactly what
he was looking for and not finding.
I just thought I might be able to use the profile idea to provide a way to
tell a parser what to look for. If they are not meant for that then that is
my mistake. I just thought I might be ab
From: "Mike Schinkel" <[EMAIL PROTECTED]>
I have a book in my hands "Definitive XML Schema" written in 2001,
published
in 2002 and it discussed Namespaces in depth. The recommendation may have
been last year, but it was not last year that the technology was available
for people to use.
And the
On Mar 6, 2007, at 2:18 AM, Joe Andrieu wrote:
Scott Reynen wrote:
On Mar 2, 2007, at 2:40 PM, Michael MD wrote:
I don't see how special cases where something has to be extracted
in a different way are expressed in the profiles.
Michael didn't see how that was expressed in profiles because
Ryan Cannon wrote:
> > Ryan Cannon wrote: Adding an @profile attribute to he
> > element is far less technically demanding than,
> > say, creating a tag space, which we also require.
> > Especially as the addition also has no performance or
> > usability impact.
> >
> > It may be less technically
Scott Reynen wrote:
> On Mar 2, 2007, at 2:40 PM, Michael MD wrote:
>
> > I don't see how special cases where something has to be extracted
> > in a different way are expressed in the profiles.
>
> Michael didn't see how that was expressed in profiles because it's
> *not* expressed in the profi
On Mar 5, 2007, at 11:23 PM, Ryan Cannon wrote:
This thread is about the necessity of profile URIs. I think the
problems
started with Scott Reynen's assertion[1] that:
> Profiles are not intended to work as parsing templates. They just
> identify the type of data so parsers can figure out wh
On Mar 4, 2007, at 11:06 PM, Mike Schinkel wrote:
Ryan Cannon wrote:
Adding an @profile attribute to he element is far
less technically demanding than, say, creating a tag
space, which we also require. Especially as the addition
also has no performance or usability impact.
It may be less tech
Karl Dubost wrote:
> > I'll give you those, but there is something
> > fundamentally different about them, i.e. they are for
> > visual presentation not logic and data encoding. And
> > there is SVG. Still, I have to ponder why tools have
> > worked there but not elsewhere. It could be simply
> >
Le 5 mars 2007 à 11:31, Mike Schinkel a écrit :
png, jpeg, gif, illustrator files, pdf, videos format?
I'll give you those, but there is something fundamentally different
about
them, i.e. they are for visual presentation not logic and data
encoding. And
there is SVG. Still, I have to ponde
Karl Dubost wrote:
> There are two schools of thinking, one of which I believe
> to be severely flawed:
>
> IMHO, more than that. :) as there are nuances in between.
True.
> > A.) Don't worry about the syntax or how it is
> > implemented, the tools will take care of make it easy.
> > B.)
Le 5 mars 2007 à 10:08, Mike Schinkel a écrit :
1.) There are two schools of thinking, one of which I believe to be
severely
flawed:
IMHO, more than that. :) as there are nuances in between.
A.) Don't worry about the syntax or how it is implemented, the tools
will take care of make
Ryan Cannon wrote:
> Adding an @profile attribute to he element is far
> less technically demanding than, say, creating a tag
> space, which we also require. Especially as the addition
> also has no performance or usability impact.
It may be less technically demanding, but the latter is needed.
>
Users should *not* be
encouraged
to publish HTML markup they cannot read.
That been happening out there in the real world with html for years with
wysiwyg editors!
... and the fact that some of them generate bad or bloated markup is not
going to stop the masses from using them.
Personally
On Sun, 2007-03-04 at 16:06 -0500, Ryan Cannon wrote:
> Adding an @profile attribute to he element is far less
> technically
> demanding than, say, creating a tag space, which we also require.
> Especially as
> the addition also has no performance or usability impact.
But one doesn't need to
On Mar 4, 2007, at 3:14 AM, Mike Schinkel wrote:
Danny Ayers wrote:
if adding a profile
attribute is hard for webmasters, the right answer is to
make it easier rather than working around its absence.
The of a HTML document is an important part of the
chain of authoritative metadata [1].
... T
Danny Ayers wrote:
> Just as an aside (and I'm open to accusations of
> "architecture astronautics" here), if adding a profile
> attribute is hard for webmasters, the right answer is to
> make it easier rather than working around its absence.
> The of a HTML document is an important part of the
>
On Mar 2, 2007, at 2:40 PM, Michael MD wrote:
Yep, a combined profile would certainly be useful. There is still
value in having multiple profiles in that it allows independent
development (and deployment), microformats at different levels of
maturity can comfortably coexist.
I've been experime
Yep, a combined profile would certainly be useful. There is still
value in having multiple profiles in that it allows independent
development (and deployment), microformats at different levels of
maturity can comfortably coexist.
I've been experimenting with trying to parse such profiles into pe
On 01/03/07, Mike Linksvayer <[EMAIL PROTECTED]> wrote:
On Wed, 2007-02-28 at 13:44 +0100, Danny Ayers wrote:
> XMDP profiles have already been drafted for many of the microformats
> (e.g. there's one for hCalendar at [4]).
Possibly stupid question: why profile_s_? (Or perhaps rather, why
prof
On Wed, 2007-02-28 at 13:44 +0100, Danny Ayers wrote:
> XMDP profiles have already been drafted for many of the microformats
> (e.g. there's one for hCalendar at [4]).
Possibly stupid question: why profile_s_? (Or perhaps rather, why
profile URI_s_.)
Microformats are specified centrally at micro
20 matches
Mail list logo
